Automatic return-based linebreaks instead of “two spaces at end of line” linebreaks

[solitud]

Hi, is there an option to turn on Automatic return-based linebreaks instead of “two spaces at end of line” linebreaks like in the GitHub Markdown parser? If not are there any plans to implement it?

I know this is discussed controversially but I think it would be a huge benefit for vanilla users, and it would help to use Markdown syntax in Forum software etc.

[standaniels]

Why is this controversially? Could you elaborate, @michelf?

I agree with @solitud, I think return character in plain text should create a <br> in HTML, because it breaks a line, doesn't it?

[solitud]

@standaniels: I think it's not in the original specifications.
Anyway, if you dare to mess with the source you find it in Markdown.php line 518:

protected function doHardBreaks($text) {
# Do hard breaks:
return preg_replace_callback('/ {2,}\n/', 
array($this, '_doHardBreaks_callback'), $text);
}

change to:

protected function doHardBreaks($text) {
# Do hard breaks:
return preg_replace_callback('/\n/',
array($this, '_doHardBreaks_callback'), $text);
}

[michelf]

Because that's what the Markdown Syntax document has to say about line breaks:

The implication of the "one or more consecutive lines of text" rule is
that Markdown supports "hard-wrapped" text paragraphs. This differs
significantly from most other text-to-HTML formatters (including Movable
Type's "Convert Line Breaks" option) which translate every line break
character in a paragraph into a <br /> tag.

When you do want to insert a <br /> break tag using Markdown, you
end a line with two or more spaces, then type return.

Yes, this takes a tad more effort to create a <br />, but a simplistic
"every line break is a <br />" rule wouldn't work for Markdown.
Markdown's email-style blockquoting and multi-paragraph list items
work best -- and look better -- when you format them with hard breaks.

[standaniels]

Ah, yes, other tags might break when \n\r == <br>, didn't think of that.

Is t a bug then, that when I want to start a list after a <br> it won't be created? For example:

Test<space><space>  
1. Option
2. Option
3. Option

Results in:

<p>Test<br>
1. Option
2. Option
3. Option</p>

If so I'll create a new issue for this.

[michelf]

No, that's a separate thing that has nothing to do with <br>. Lists must be separated by a blank line to protect you from making accidental lists with hard-wrapped text:

This is a paragraph about the lot number
1. But lot number 2 is better, like number
3. Which lot do you want?

The above is not meant to be a list. The blank line is not necessary for sublists.

[mjau-mjau]

@solitud thanks for your solution to line breaks.

I'm wondering, are there really any downsides to using this fix? I can't seem to think of anything. It's even backwards compatible ... I don't see, from a text-editors perspective, why a line-break should not incur the same result in the rendered output.

[jcohlmeyer]

Just my opinion, but I think relying on two spaces at the end of a line for a line break is a bit weird and prone to bugs, especially when we have the well established rules for line breaks with \n

Are there downsides to implementing this change mentioned by @solitud that can not be easily worked around, even though it is not sticking to the Markdown spec?

[jackmcdade]

I see both sides to this. The Markdown spec hasn't changed in 12 years, but the web and authoring tools have changed significantly. That's why we've seen a rise in the popularity of Github Flavored Markdown.

Unfortunately, there are really no PHP libraries that support GFM completely. I think there is definitely a place for adding a few new conventions here and there. This one in particular relies on invisible characters, which makes it a a weak feature, unless you're using a code editor with invisible character display.

All that to say, I think this solution has merit as a config option perhaps, but not default behavior. That way you get the best of both worlds. Flexibility, and backwards compatibility.

[michelf]

Note that even the Github Markdown parser has two modes: one where the line breaks are significant and one where you must end the line with two spaces to insert a line break. The first mode is used for comments forms (like here), while the second mode is used for parsing Markdown documents in repositories (like the Readme.md files).

There is no way around the fact that this is not a backward-compatible change: any document with line breaks in it assumes either one or the other behavior from the parser, and if you change the behavior you add or remove line breaks from the document. We could add however a separate mode in PHP Markdown that mirrors more closely Github's comment mode.

[jackmcdade]

@michelf exactly.

[mjau-mjau]

@michelf can you explain how it is not backwards compatible?

1. markdown code:
   
2. render flawless, even if the line-breaks had double-spaces from previous legacy:
   

I can only see it's not backwards compatible if someone already went through the pain to use <br> tags because it was more convenient than double-spacing. It's certainly backwards compatible with existing pages where double-spaces WERE in fact used ... obviously they have no other effect than exactly that: two empty spaces after some text.

Reading up on the origin of this strange rule, I can't really find anything tangible for the modern age. It seems to be it's there just to prevent the user from using single-line breaks to separate texts, as technically-speaking, it is incorrect from a pure text-writing perspective to have line-breaks without a new paragraph. However, when used to edit web-content, we often need the single line-break to separate links, or just add text below a <strong> tag.

[jackmcdade]

@mjau-mjau If you like to write like this...

Hello there.
This is how I write sometimes.
It looks good in my editor, and follows my train of thought.

And have the output be:

Hello there. This is how I write sometimes. It looks good in my editor, and follows my train of thought.

You'd be out of luck.

[mjau-mjau]

@jackmcdade why would you write like that if you didn't want it to appear like that?

[jackmcdade]

@mjau-mjau It doesn't matter why I would write like that. Right now I can write like that. And if you change the behavior, that's what wouldn't be backwards compatible.

[mjau-mjau]

if you DO in fact write like that (which I doubt very much), then yes it would render like how you have written it, instead of compiling to a single line.

It's not a good reason.