Tildes should not use hard line breaks for line endings
I'm new to Tildes, but I've been using Markdown-based comment systems
for more than a decade: both Reddit and GitHub. My programming blog has
been written in Markdown for the past 8 years. Overall I've probably
written several novels worth of content in Markdown in my life.
I've already noticed that Tildes has made a serious mistake in its
handling of line endings: All line endings are treated as hard line
breaks. This diverges from CommonMark and most uses of Markdown in
practice. If I wanted a hard line break, I'd put two spaces at the end
of the line, as specified by both CommonMark and the original Markdown.
Line endings should be otherwise be soft.
GitHub made the same mistake with its "GitHub-flavored Markdown," though
fortunately this mistake has been limited to issues. GitHub README.md
files don't have this behavior, nor does GitHub Pages. It the only other
Markdown system I've used with this flaw.
Why does this matter? If I'm writing more than a single sentence, I
never edit my comment inside my web browser. I edit it using my text
editor of choice, Vim, since it's far more comfortable. I don't even
have to copy-paste the text between applications. Instead, I have an
add-on, Tridactyl, that does this seemlessly and effortlessly.
Hard line endings just don't work well with long prose — exactly the
type of content that Tildes is encouraging — particularly when edited in
a proper text editor that knows about paragraphs and can do its own line
wrapping. Editing long lines is annoying and takes extra care. That's
why we have soft line endings after all.
I'm leaving all my line endings in this post so that you can see the
mess Tildes makes with it, with the ragged right-hand side due to font
differences. If I had written this in nearly any other Markdown system,
the text would have flowed into the page without issues. It is a mistake
for Tildes to do differently. This sort of compatibility issue is
probably going to be annoying enough to keep me off the site.
Just copy-pasting my comment from the merge request:
Using hardbreaks was a deliberate choice, and I don't plan to change it. I recognize it's inconvenient for you, but not using it is inconvenient for the huge number of other people that inadvertently post walls of text because they expect that typing a line break will result in... a line break, like it does in almost every other context.
If you're using vim, it would be straightforward to create a macro or function that removes all your line breaks, so you can write as you're used to and then just press a single key combo when you finish your post and get the result you're expecting.
oops, I thought this had been the behaviour since the open-sourcing – do you have a link to the MR? I wonder how I missed it.
The obvious solution,
:%s/^M//
(where^M
is a literal carriage return), presumably won't work, because afaict that would join everything onto one line. I guess you'd have to do something like:%s/\v^(.+)^M/\1/
to avoid removing empty lines, or do something with:g
or:v
? I'm unconvinced that counts as "straightforward".You're right, this has been the behavior since forever. But OP submitted a merge request to change this behavior.
You're probably very close to solving it with maybe a minute or two of thought and a relatively basic regex that's about 10 characters long. That's fairly straightforward.
There should be plenty of other methods as well without needing to use regex. For example, you can set
textwidth
to a huge value and do something likegggqG
(gg
= "go to start of file",gq
= "rewrap text from here until...",G
= "end of file"). So you could make something settextwidth
very high, rungggqG
, and then re-settextwidth
back to what it was before.I'm sure there are instructions somewhere on StackExchange for dealing with exactly this need as well, and probably even existing vimscripts/plugins.
Incorrect (
:h gq
):Oh, alright. Set
textwidth=100000
or something instead of zero then (thanks, edited my previous post with that).I have no real problem with what you are asking for, especially since it looks like you have submitted the change yourself, but please work on the phrasing when making requests like this. You are asking for what amounts to a convenience feature for an extreme edge case, so please don't add a melodramatic "add this or kiss me goodbye" ultimatum.
Sorry, I didn't mean for this to come off as an ultimatum. That's just the reality of it. I've abandoned or ignored plenty of other platforms and software for similar negative UI experiences. For example:
Twitter is a huge, popular platform, but I hate pretty much everything about its UI. Because of this, I never bothered registering an account, and I only follow links to Twitter by accident (and immediately back out of them).
YouTube's comment system seems like it's designed to discourage its use. I tried using it for awhile since it's the only way to interact with some YouTubers. I even jumped through the Google+ hoops in order to keep commenting, but eventually I gave up because it's so bad and useless.
Google+ was awfully designed. For several years the site didn't even page-scroll properly in Firefox. Even if it wasn't a ghost town I would never have used it just because of its bad UI.
Patreon's website is so slow and clunky. My laptop fan spins up soon after I log into the site. Two years ago I got so irritated with it that I completely stopped using. I was supporting two different content creators at the time. (Fortunately one of them accepts donations via other means.)
I don't even bother following Medium links anymore. I'm tired of adding dickbar-removal rules to my adblocker. On Reddit I just downvote them and move on.
If Reddit ever gets rid of its "old" interface, I would immediately stop using it. I tried the redesign and I just can't stand it.
In the case of those first five, I never voiced my opinion about my problems with their sites. That would be a waste of my time. They're huge and have no interest in changing. It's also not very difficult for me to ignore these sites, so that's what I do.
I want to like Tildes, and it's still young and small enough that something like this really could change. So much else about this site is done really well. That's why I took the time to comment on the line breaks. I'm on the "voice" part of "exit, voice, or loyalty."
I don't think it's as extreme as you think it is. Tildes just isn't active enough yet for people to really notice. If you do a search, you can find lots of discussion online going back years about GitHub-flavored Markdown catching people off-guard. Technical writing is particularly sensitive to this sort of thing since it requires extra precision.
Besides, getting these "edge cases" right is important. For example, GitHub supports an email-based workflow, but I bet more than 99% of its users aren't even aware of it. I suppose that makes it an "extreme" feature. (GitLab might support this too, but I haven't used it enough to know.) You can reply to issues, pull requests, etc. entirely from email. so most things can be handled through a combination of Git and email without touching a web browser... and it's awesome. I wouldn't respond to half the issues/PRs I get on GitHub if it weren't for this little feature.
Supporting an email workflow doesn't break something else for the 99% of users you talk about, it just doesn't do anything for them. What you're asking for is behaviour that is expected of the 1%, and unexpected of the 99%.
I'll also add, the examples you bring up about Twitter, Reddit's new UI, Medium and G+ are very much unlike your example here. Those are platforms whose UIs have a huge amount of dislike. Reddit's new UI is near-universally despised by its legacy users, Twitter is so famously confusing its CEO has trouble with it, G+ is being shut down, and Medium is being shunned by all the users who originally praised its revolutionary-at-the-time UI.
I can relate. I swore off mobile Apple products because they don't have native Dvorak support - definitely an edge case situation.
I much prefer how Tildes handles line-breaks to Reddit. If I want to end a line early I don't want to have to insert an additional line break between that and the next line, as it's a pain, easy to forget and doesn't feel intuitive. I similarly dislike how markdown ignores the number in numbered lists, but I think that behaviour is the same on Tildes too.
I'd say Tildes current behaviour in this area is within the expectations of most users also, and is easier for non-technical users to understand: typing on a new line means that text appears on a new line, not magically jumping back up a line.
What exactly do you mean by hard line endings not working with longer prose? I've noticed zero issues so far on Tildes related to there being extra spacing/not enough spacing in longer posts or comments.
I take it you insert line breaks so that you don't need to scroll across the terminal for longer lines when typing up a post in vim? Wouldn't simply using
set wrap
work so that lines are wrapped in the terminal resolve this? Your particular work flow seems quite unique.This is one of my favorite features of markdown. Simply use
1.
for every item - adding a new item in the middle of a long list doesn't require manual adjustment of every subsequent number.I agree. That is a part of Markdown that I've always disliked.
What I described essentially how programmers have been writing prose in plain text for decades, wrapping a monospace font to 80 columns in a text editor. If it's processed by another system (TeX, troff, Markdown, etc.), then that next system reflows the text as needed (font settings, etc.). It's exactly the sort of thing Markdown was originally modeled after, particularly plain text email.
Right, I understand that. But in the same way most people don't write plain text email from a terminal nowadays, most people don't write markdown comments for a website in an instance of vim but in the input field of their browser.
While I almost always write my comments in the browser, I can imagine that an external editor is handy for longer texts. Just recently I had lost a longish comment I have written, because Chrome crashed (on my phone, but it could happen elsewhere). My text editor would have an auto save option.
Then if you have a full-screen terminal, you get text across the entire screen, which is a pain to read.
You could resize the terminal window? I mean a full-screen terminal window that has line breaks every 80 characters or so is going to leave a lot of wasted space anyway.
Consider creating an issue, and manually removing single linebreaks from your text, for example with a search-and-replace like function. It is currently very annoying to read.
Good idea, thank you.
Edit: https://gitlab.com/tildes/tildes/merge_requests/56
Here's the rub: Right now it's far easier for me to simply stop using Tildes than work around its idiosyncratic Markdown. I'm hoping this is just an oversight rather than an intentional design choice, because if it's the latter then it's unlikely to change.
Tildes is still pretty new so not everything is polished up yet. This isn't likely a design choice and will be fixed eventually if an issue is made. Tildes is also open source and you can fix it yourself. But if you don't have the necessary skills you'll have to wait. But if really suggest finding a simple work around until then. Tildes is nice and worth the effort.
The way default Markdown handles line breaks is nonsensical at best. Especially for platforms like Tildes and Reddit. The default way is good for like Git or README.md's where half the time you're going to be looking at the raw source text in a narrow terminal. But here? It's just completely nonsensical and 1000% unintuitive for 99.99% of users. Breaking that just for your work flow seems a bit silly.
Tildes appears to have been doing this since it was open-sourced:
(source)
The
--hardbreaks
option to cmark is documented in its man page:Both of these should render identically according to CommonMark:
but they don't on Tildes (as of 2019-02-17):
This paragraph is not wrapped; all text is on one line. If your window is thin enough, your browser will insert soft line breaks so that you don't have to scroll horizontally to read it.
This paragraph is
hard-wrapped to 20
columns wide. No
line will contain
more than 20
characters.
https://spec.commonmark.org/0.28/#soft-line-breaks:
A
<br>
is neither a line ending (U+000A) or a space, so Tildes is not adhering to the standard.Like I had said in my post, the majority of Markdown processors don't have this behavior, and they treat line feeds as if they was any other whitespace, just like HTML. That's how the original Markdown was specced. As you noticed, Tildes enables a special, non-default option in order to get this behavior.
Now that I'm reading this it also suddenly shows how large the line spacing is. A few pixels less feels less bloated, l would say.
Please no. It is pleasantly spacious and anything less would be too compressed.
edit: typo
Guess this is something for custom css on my end, maybe there's an extension for that or something.
There is... Stylus:
https://addons.mozilla.org/en-US/firefox/addon/styl-us/
And the style script that does what you're looking for would be:
Change the line-height value to whatever you prefer. Just keep in mind that anything below 1.0 results in overlapping text.
p.s. If you have chrome there is a Stylus extension for it as well, though I don't have it installed so can't tell you what the "moz-document" part needs to be changed to in order to make it work on that.
LOL... I figured you would chime in with a better version. In my defense, I wrote that at 4am last night and did at least consider restricting it to
<p>
... but just couldn't muster the energy to test the results first. :Pp.s. Thanks for making me realise I can use CSS in the syntax highlight feature. I will have to do that from now on.