Tag-raw does not display leading spaces

[Zabuzard]

Introduction

Discord seems to not render leading spaces on a message (unless it is inside a formatted code block).

Input like

results in

Problem

This is not new and also not really a "bug". However, it becomes a problem with the /tag-manage raw command. See this:

The tag-raw command intentionally removes code blocks so that we can copy paste the raw text to edit it. But that leads to leading spaces in the code being stripped. So the copy-pasted code is fully left-trimmed.

This makes the tag-raw command barely usable in practice, very cumbersome.

Ideas

Dyno attempts to fix this by putting the raw content into a code block, this fixes the left-trimming issue but introduces a much bigger problem... If everything is put into a code block, we cant have code blocks in the text anymore, since they would otherwise exit the surrounding code block otherwise... (leading to the mess of why dynos tag-raw was even worse UX for us the last years).

To be honest, I do not really have any nice solution right now...

Research lead to this discussion which suggests replacing leading spaces by whitespace-ish characters that look like space but are not, hence Discord does not touch it.

I guess that could fix our problem. Kinda dirty though.

Proposal (from comments)

A simple and good fix would be to not try to hack our way through Discords rendering quirks and instead bypass the regular message system by sending file attachments.

So instead of replyEmbed(...) we basically could do sendFile(...) and send the content as file (for example with .md extension). That way, Discord will not mess up anything about the message content and users can get the original content easily.

This also does not interrupt the flow to create/edit tags afterwards, since it nicely synergises with /tag edit-with-message after posting the edited message content in Discord again.

As a note, this might make #269 obsolete (we can still keep it as general purpose helper though). In fact, /tag raw might not need any sort of escaping with this file-fix anymore.

[Zabuzard]

Discord master @Tais993 any idea on this? 😬

[Zabuzard]

Just tested, Discord indeed leaves the braille-pattern-blank as it is (⠀, https://www.compart.com/en/unicode/U+2800).

The only "problem" I see is that when people copy paste the actual visualized text then (i.e. actual end users):

if (true) {
⠀⠀System.out.println("Hello");
}

They have braille-blanks in their real code instead of whitespace or TAB, which do not compile:

While fixing the issue, this leads to a worse UX in the end. I rather have the additional annoyance on the tag maintainers (us) than on the end user.

It can be made working though by replacing them against spaces on tag-edit/create again; just kinda dirty.

[Tais993]

Honestly, best solution would be to send the tag as a .txt file I'd say.

This solves everything, and a .txt is nice to edit.

[Zabuzard]

Honestly, best solution would be to send the tag as a .txt file I'd say.

This solves everything, and a .txt is nice to edit.

Actually, this is a very interesting idea. Sounds rather simple to do code-wise as well, right? Just sendFile, with the string as UTF-8 bytes.

[I-Al-Istannen]

Or as .md so you get syntax highlighting :)

[Zabuzard]

As a note, I already wrote the fix for the "dirty hack" I mentioned earlier. I leave the PR (closed) there and the branch alive, in case the file-approach does not work out or anything.

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[Zabuzard]

Issue is still valid, a good first issue and rather easy to fix. Reopening.