nheko
nheko copied to clipboard
Consider supporting emitting linebreaks without needing to enter a double linebreak
Describe the bug
hello
How *are* you?
It gets rendered as,
hello How *are* you?
In such cases,
hello <br>
How *are* you?
works though
To Reproduce
While talking in a room, (with Markdown turned on), Type anything with italics and new line Like,
Hello
I *am* random name
What happened?
It gets rendered as,
Hello I *am* random name
Expected behavior
It gets rendered as,
Hello
I *am* random name
Screenshots

Version
0.8.2-33ad65dc | Linux
Operating system
Linux
Installation method
Flathub
Qt version
No response
C++ compiler
No response
Desktop Environment
No response
Did you use profiles?
- [ ] Profiles used?
Relevant log output
No response
Backtrace
No response
This newline behavior is valid markdown. Try putting a double space (i.e. " ") after "Hello" or adding a double newline instead of a single newline.
That works @LorenDB Thanks
On the other hand, would a feature request to use new lines without " " be feasible?
I don't really understand the issue. We always require double linebreaks to send a linebreak, because we do use standard markdown. Apart from you preferring single linebreaks, is there anything specific to italics in this issue?
Nope Although I guess it'd be worth it to have an option for that in Settings? From the perspective of, not everyone knows what "markdown" is, but would want certain "features" as strikethrough or newline without two spaces (for the common user, strikethrough and bold and italics would be "features" more so than "part of markdown")
I'd like to chime in that surely it should be considered a bug that the text input field shows a message as having a linebreak (having pressed enter once), but the sent message does not show a linebreak? I get the technical reasons for this, but I know non-technical users who've gotten confused by this.
Considering that text after a # gets written in big letters, * can make stuff italic or bold, etc, I don't think it should be that surprising, that the message input is not a rich text editor but a markup editor. I think keeping single linebreaks makes more sense in a rich text editor, which might make sense to add in the future.
As a developer who's used to markdown in other contexts and used to various chat apps, it's surprising to me that enter doesn't give me a linebreak in nheko regardless of the technical reasons.
For instance here while writing a comment in the github UX which support (github-) markdown I can press enter- and voila, I get a newline.
IMO it should be a toggle in the settings, with the default being the linebreak functionality "everyone" (citation needed I guess) is used to. I don't mean to argue this too much since ultimately it's up to nheko what it wants to be and that's fine.
For those just looking for a work-around, pressing ctrl+space in nheko will give you a "normal" newline (thin line-speaking, instead of a new-paragraph-line-spacing).
Just dropping this here, I hope I'm not offtopic. While
does work for me, double space at the end of the line does no longer result in a linebreak for me for a while. I think this was different a few months ago.
I find it quite cumbersume to always type br or add an empty line (also because the latter results in different formatting).
What's the current suggestd behaviour to create a simple line break in markdown mode?
Just dropping this here, I hope I'm not offtopic. While does work for me, double space at the end of the line does no longer result in a linebreak for me for a while. I think this was different a few months ago.
The commonmark library (correctly) inserts <br /> and it is sent, but the Qt widget Nheko uses to display messages only understands <br> (without /).
I find it quite cumbersume to always type br or add an empty line (also because the latter results in different formatting).
What's the current suggestd behaviour to create a simple line break in markdown mode?
Either insert <br> by hand, or use two or more spaces at the end of the line or a backslash (\). This will render correctly in other clients but not in Nheko.
(Note that <br /> isn't really part of modern html, so saying the library is "correctly" emitting it is not entirely correct, since one would assume it uses the canonical tag for line breaks)
Adding a space after a line (or 2?) should now work again. The problem was neither Qt or cmark, it was us replacing <br/> tags with <br//>, because we thought the empty space before the / was an attribute.
So I am wondering what to do with this. While I do agree, that needing double linebreaks or 2 spaces after a line is surprising, I do think it has payoffs in the long term, since it works the same as in standard markdown. It isn't hard to split text nodes at each \n and insert a br tag there, but I'm just not sure I want to have that as a feature. I don't really want to add another option, so we should settle on one way to do it. I guess I will just let this issue sit again for another year, unless someone has some good data to argue either case :D
The only reason i can see not to turn a single \n into a <br> is that text might be copied from elsewhere, maybe a file with a certain text width limit and thus non-significant line breaks. Surely no one inserts a new line by hand into the input box and expects it to be turned into a space?
I'm in favour of inserting <br> tags because it is very confusing that newlines are treated differently for plain text and Markdown/HTML.
Well, I do copy my release notes into Nheko all the time and removing all the line breaks would be annoying :D
Also, there is no plain text now anymore, that you can send accidentally by just having text with a newline. Only way to do that is by forcing it using the settings or /plain. Otherwise a \n triggers the content to be sent as markdown, so it is always treated as a space: https://github.com/Nheko-Reborn/nheko/commit/872b00807fc03d6caf4e4b487880047261f21c08
So, turning soft linebreaks into hard ones is apparently a single line change. As such an option wouldn't be that much effort to support: change https://github.com/Nheko-Reborn/nheko/blob/master/src/Utils.cpp#L916 to const char *tmp_buf = cmark_render_html(node, CMARK_OPT_UNSAFE | CMARK_OPT_HARDBREAKS);
Not sure yet if I want that as an option, the default or not at all though :)
test secondline
Interesting, Github also does linebreaks without double linebreaks.
Yes, GitHub markdown has a different setting for text boxes (for the convenience of users) and documents. We adopt the same behaviour for Codeberg/Forgejo/Gitea.
My proposals:
Default: markdown, but simple newline triggers a newline /md as a command enters real markdown mode where line breaks are ignored unless there are two spaces (can be used in rare cases where you really want full markdown)
Or:
Simple line breaks, unless explicit line breaks are detected which switches to the full markdown mode.
Let me add two comments: I think the main confusion for me was started because nheko does not render the two spaces even if the br is emitted, which made me think that nheko does not allow any way to send line breaks in messages (I only use nheko, so there was no other client to confirm that line breaks work the way I expected, but nheko does not display them).
And: if you just quickly want to type a message, and don't really care about Markdown (probably the majority of users that are not here in the issue tracker), or just require pretty basic formatting (like italic and bold), you'll notice that pressing enter or shift-enter for a line break is by far the easiest behaviour instead of space-space-shift-enter. That's exactly the reason GitHub breaks the line when you do a simple line break.
Yeah, I heard the extra command for standard markdown a few times now and I do think that is sane. /md already exists though, so we would probably pick /commonmark or so.
Or we could do /rich for regular rich text and then /md would force strict Markdown. Alternatively, we could keep /md and use something like /md-strict for strict Markdown.
or we just use the name of the specific markdown spec, like commonmark or cmark :D
Sure, but the shorter the command name, the better, IMO
cmark is pretty short, but also this is mostly for pasting large docs, you probably have time to use the completer.