Because it is how the format is defined. There is nothing to fix. You write text in paragraphs by default and if you want it to be displayed in any other way you need to declare it. Most formatting is done before the text, like headings and lists, but this newline without a new paragraph is declared with two trailing spaces.
Comment on Why does not a CR (Carriage Return) automatically start a new line on some online text editors?
schipelblorp@sh.itjust.works 2 weeks agoAh, so that’s where it starts, but why isn’t it “fixed”? What benefit is there to leaving it like that?
People are writing text, not code and they’re expecting the editor to the heavy lifting.
whaleross@lemmy.world 2 weeks ago
schipelblorp@sh.itjust.works 2 weeks ago
I
declare
it
by
hitting
an
entire
button
dedicated
to
making
a
new
line that
also
makes
a new
line
in
the
editor
I’m
looking at
creating
a
new
line.It doesn’t make sense from a user perspective, whatever the format is.
whaleross@lemmy.world 2 weeks ago
Well, you are free to declare your own flavour and try get it supported by whatever editors and libraries you use. Damn, you can make up your own format that works in any particular way you want to. I bet in this time and age you could vibe code it with functions to your heart’s desire.
But bitching about it to people that are trying to be helpful and explain why it is like it is will not render much other result than said people dropping you into their blocklist for being annoying.
schipelblorp@sh.itjust.works 2 weeks ago
Fair. Apologies.
This issue is that you gave me kind of a detailed answer that didn’t really answer my question: What is the BENEFIT of doing it this way in the face of unexpected behavior to a naive user? Two answers others have given are that it allows easier cut-and-paste, and it allows users to break up their text for their own readability on narrower displays while still allowing it to be formatted to fit the final screen.
Damn, you can make up your own format that works in any particular way you want to.
Speaking of blocklists…
blackbeans@lemmy.zip 2 weeks ago
I’m with you on this one. The behavior is not as people would expect it.
Hitting enter/return should result in a newline. That’s what users expect.
The UX is inconsistent because it shows a newline in the entry screen, yet doesn’t show it after submitting.
schipelblorp@sh.itjust.works 2 weeks ago
I’ll say that the formatting options with the /* and the /_ and the /** are all pretty awesome. I wish every editor was like that.
TootSweet@lemmy.world 2 weeks ago
Because it is useful to many people in certain contexts. It’s not a bug. It truly is a feature. Not something to be “fixed”.
You may prefer your ice cream strawberry flavored, but that doesn’t mean any ice cream that is instead chocolate flavored is “defective” and needs to be “corrected” or “fixed” to make it strawberry flavored.
blackbeans@lemmy.zip 2 weeks ago
It can help to give an analogy. But in this case it would be more clear if you would demonstrate the usefulness of this feature by explaining why a user wants to prefer to hit enter and not get any result, instead of hitting enter and getting a newline.
TootSweet@lemmy.world 2 weeks ago
lemmy.world/post/49360492/24735359
Also:
You mean “hit enter and have it not affect the rendered output.” It does produce a result. It makes it appear/act differently in the editor. That’s not “not getting any result.” Just “not getting any result” that’s visible in the rendered output.
blackbeans@lemmy.zip 2 weeks ago
Why would a user want a different appearance in the editor compared to the final result? This is a discussion platform, not a code editor.