23 votes

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.

33 comments

  1. [6]
    Deimos Link
    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...
    • Exemplary

    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.

    38 votes
    1. [5]
      anowlcalledjosh Link Parent
      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...

      from the merge request

      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.

      If you're using vim, it would be straightforward to create a macro or function that removes all your line breaks

      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".

      4 votes
      1. Diff Link Parent
        You're right, this has been the behavior since forever. But OP submitted a merge request to change this behavior.

        You're right, this has been the behavior since forever. But OP submitted a merge request to change this behavior.

        7 votes
      2. [3]
        Deimos (edited ) Link Parent
        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...

        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 like gggqG (gg = "go to start of file", gq = "rewrap text from here until...", G = "end of file"). So you could make something set textwidth very high, run gggqG, and then re-set textwidth 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.

        5 votes
        1. [2]
          anowlcalledjosh Link Parent
          Incorrect (:h gq):

          So you could make something unset textwidth, run gggqG, and then re-set textwidth back to what it was before.

          Incorrect (:h gq):

            	If the 'textwidth' option is 0, the formatted line
            	length is the screen width (with a maximum width of
            	79).
          
          4 votes
          1. Deimos (edited ) Link Parent
            Oh, alright. Set textwidth=100000 or something instead of zero then (thanks, edited my previous post with that).

            Oh, alright. Set textwidth=100000 or something instead of zero then (thanks, edited my previous post with that).

            4 votes
  2. [4]
    Akir Link
    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...

    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.

    23 votes
    1. [3]
      skeeto Link Parent
      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...

      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."

      You are asking for what amounts to a convenience feature for an extreme edge case

      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.

      9 votes
      1. Adys Link Parent
        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%,...

        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.

        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.

        5 votes
      2. Guyon Link Parent
        I can relate. I swore off mobile Apple products because they don't have native Dvorak support - definitely an edge case situation.

        I can relate. I swore off mobile Apple products because they don't have native Dvorak support - definitely an edge case situation.

        2 votes
  3. [7]
    apoctr Link
    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...

    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.

    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.

    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.

    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.

    18 votes
    1. andre Link Parent
      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 similarly dislike how markdown ignores the number in numbered lists

      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.

      7 votes
    2. [3]
      skeeto Link Parent
      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...

      I similarly dislike how markdown ignores the number in numbered lists

      I agree. That is a part of Markdown that I've always disliked.

      Your particular work flow seems quite unique.

      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.

      4 votes
      1. [2]
        apoctr Link Parent
        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...

        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.

        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.

        20 votes
        1. ali Link Parent
          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...

          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.

          3 votes
    3. [2]
      anowlcalledjosh Link Parent
      Then if you have a full-screen terminal, you get text across the entire screen, which is a pain to read.

      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?

      Then if you have a full-screen terminal, you get text across the entire screen, which is a pain to read.

      2 votes
      1. apoctr Link Parent
        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.

        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.

        5 votes
  4. [3]
    deing Link
    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.

    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.

    14 votes
    1. [2]
      skeeto (edited ) Link Parent
      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...

      Consider creating an issue

      Good idea, thank you.

      Edit: https://gitlab.com/tildes/tildes/merge_requests/56

      manually removing single linebreaks from your text

      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.

      7 votes
      1. Rocket_Man Link Parent
        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...

        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.

        7 votes
  5. Diff Link
    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...

    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.

    13 votes
  6. anowlcalledjosh Link
    Tildes appears to have been doing this since it was open-sourced: # enables the --hardbreaks option # (can I import this? it's defined in cmark.h as CMARK_OPT_HARDBREAKS) cmark_options = 4...

    Tildes appears to have been doing this since it was open-sourced:

        # enables the --hardbreaks option
        # (can I import this? it's defined in cmark.h as CMARK_OPT_HARDBREAKS)
        cmark_options = 4
    

    (source)

    The --hardbreaks option to cmark is documented in its man page:

    Render soft breaks (newlines inside paragraphs in the CommonMark source) as hard line breaks in the target format. If this option is specified, hard wrapping is disabled for CommonMark output, regardless of the value given with --width.

    9 votes
  7. [5]
    Bauke (edited ) Link
    I'm pretty sure Tildes doesn't intentionally convert any line-endings like that? As well that Tildes uses cmark, the C reference implementation for CommonMark. See for yourself here.Edit: Tildes...

    I'm pretty sure Tildes doesn't intentionally convert any line-endings like that? As well that Tildes uses cmark, the C reference implementation for CommonMark. See for yourself here.Edit: Tildes does do it

    Also, what are hard line endings and soft line endings? I don't think I've ever heard of that before.

    2 votes
    1. [4]
      anowlcalledjosh Link Parent
      Both of these should render identically according to CommonMark: 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...

      Both of these should render identically according to CommonMark:

      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.
      

      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.

      6 votes
      1. [3]
        Bauke Link Parent
        I know that the browser will wrap, but if you add linefeed characters U+000A: LINE FEED (LF) like you do there it will convert those to <br> and that sounds normal to me?

        I know that the browser will wrap, but if you add linefeed characters U+000A: LINE FEED (LF) like you do there it will convert those to <br> and that sounds normal to me?

        3 votes
        1. anowlcalledjosh Link Parent
          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.

          https://spec.commonmark.org/0.28/#soft-line-breaks:

          A regular line break (not in a code span or HTML tag) that is not preceded by two or more spaces or a backslash is parsed as a softbreak. (A softbreak may be rendered in HTML either as a line ending or as a space. The result will be the same in browsers. In the examples here, a line ending will be used.)

          A <br> is neither a line ending (U+000A) or a space, so Tildes is not adhering to the standard.

          6 votes
        2. skeeto Link Parent
          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...

          and that sounds normal to me?

          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.

          4 votes
  8. [6]
    asoftbird Link
    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.

    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.

    1 vote
    1. [5]
      masochist (edited ) Link Parent
      Please no. It is pleasantly spacious and anything less would be too compressed. edit: typo

      Please no. It is pleasantly spacious and anything less would be too compressed.

      edit: typo

      9 votes
      1. [4]
        asoftbird Link Parent
        Guess this is something for custom css on my end, maybe there's an extension for that or something.

        Guess this is something for custom css on my end, maybe there's an extension for that or something.

        2 votes
        1. [3]
          cfabbro (edited ) Link Parent
          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: @-moz-document domain('tildes.net'){ html {...

          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:

          @-moz-document domain('tildes.net'){
          html { line-height: 1.5; }
          }
          

          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.

          4 votes
          1. [2]
            Bauke (edited ) Link Parent
            It doesn't need to change, if you paste that into Stylus directly it will use it to determine the domain it needs to be applied on. Also I recommend not putting it on html but rather...

            It doesn't need to change, if you paste that into Stylus directly it will use it to determine the domain it needs to be applied on.

            Also I recommend not putting it on html but rather .topic-full-text (and any other classes you specifically want), otherwise you will increase the line height of everything and that can lead to... undesirable results.

            @-moz-document domain('tildes.net'){
              .topic-full-text {
                line-height: 1.5;
              }
            }
            
            5 votes
            1. cfabbro (edited ) Link Parent
              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...

              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. :P

              p.s. Thanks for making me realise I can use CSS in the syntax highlight feature. I will have to do that from now on.

              2 votes