GFM-style line breaks not supported #12

Closed
adam-p opened this Issue Jun 7, 2012 · 10 comments

Projects

None yet

4 participants

@adam-p
Owner
adam-p commented Jun 7, 2012

Due to a bug in the Markdown renderer we use -- chjj/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 adam-p/markdown-here#9.)

@crdx
crdx commented Sep 25, 2012

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

@adam-p
Owner
adam-p commented Sep 25, 2012

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
crdx commented Sep 26, 2012

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

@stof
stof commented Jan 27, 2013

marked now supports the GFM line breaks

@adam-p
Owner
adam-p commented Jan 27, 2013

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
crdx commented Jan 27, 2013

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

@adam-p
Owner
adam-p commented Feb 6, 2013

Added in Markdown Here v2.7.0, released today.

@adam-p adam-p closed this Feb 6, 2013
@crdx
crdx commented Feb 6, 2013

Nice!

@ase34
ase34 commented Sep 10, 2013

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

A line
Another line

will get "A line Another line"?

@adam-p
Owner
adam-p commented Sep 30, 2013

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment