adam-p/markdown-here

GFM-style line breaks not supported

Closed this issue · 10 comments

Due to a bug in the Markdown renderer we use -- markedjs/marked#51 -- GFM-style line breaks are not supported.

So, in Github, this Markdown will render to two lines, but in Markdown Here it'll be one line:

line the first
line the second

(This bug is forked from #9.)

crdx commented

This is fixed in #7, isn't it?

No. Perhaps you're thinking of the "end a line with two spaces for a newline" feature of the Markdown syntax? That was broken by #7 (and fixed by its fix).

To reproduce this bug, try it out in a Github issue and in Markdown Here. Just two simple lines (with no trailing spaces):

abc
xyz

Here's the rendering of that in Github (GFM):

abc
xyz

In Markdown Here it'll render like this:

abc xyz

I wish you were right, so I could close another bug, but...

crdx commented

Oh, I see. That's a deviation from the original markdown spec, I believe. I'm surprised GFM does that.

stof commented

marked now supports the GFM line breaks

You are correct. I've incorporated the new Marked code and the fix will be in the next version. (Along with tables!)

I'll close this issue when I've released the change -- within the next couple of weeks.


For posterity: I struggled with whether to enable the GFM line breaks or not.

Against GFM line breaks:
I think it's the worst additional feature of GFM, and I understand chjj's decision to disable it by default. I think it violates one of the (if not the) central goal of Markdown: that the both the plaintext and rendered Markdown should be readable (and perhaps even look good). For plaintext I think that "readable" implies "lines broken at 80 characters", but then that messes up the rendering. So you end up with READMEs like mine, where the lines are unbroken. (Yeah, sure, any reasonable editor can wrap lines on command, but I still think it better to not have to. See: every coding style ever.)

In favour of GFM line breaks in Markdown Here:

MDH is a different case than READMEs.

First of all, the plaintext and rendered forms are not equal; the rendered form is the real goal. Not only is it not important that the plaintext be broken up into 80 characters lines, but the vast majority of users will not be doing so (or, indeed, inserting any kind of extraneous newlines) -- that's just not what people do in email.

Secondly, I think that Markdown Here can be of great use to non-programmers, and I want it to be. What follows from that is that the more intuitive our Markdown is, the better. And I think that: a) the two-space-->newline syntax of MD is horribly unintuitive, and b) most users who aren't Markdown experts will expect that putting a newline in their raw Markdown will have a similar effect in the rendered form.

So, supporting GFM line breaks is not a significant hindrance to Markdown experts, and will probably help those who are not experts.

I welcome arguments to the contrary. Just add a comment.

crdx commented

@adam-p

I agree completely. I see nothing intuitive about having to type two spaces at the end, and I don't see much of a disadvantage from making a newline in the markdown equal a newline in the rendered output.

On reddit, so many people write lists as one item on each line, which of course gets rendered all on one line, and they rarely notice that the formatting is messed up (or if they notice, they don't fix it). I think it should be markdown standard.

Added in Markdown Here v2.7.0, released today.

crdx commented

Nice!

Is there a way to disable the GFM line breaks so that

A line
Another line

will get "A line Another line"?

@ase34: I made a new issue for your request: #103