4 ms·

Oh, he didn't mention half the stuff I thought he would. He's right about a lot of things though. Take this for example: Hello world, there isn't 1. T

by chjj 13y ago

Oh, he didn't mention half the stuff I thought he would. He's right about a lot of things though. Take this for example: Hello world, there isn't 1. There are 4. The original markdown treats the second line as a continuation of a line in a single paragraph. Github treats the second line as the start of an ordered list. Why? Because then you can do things like this: # My list 1. foo ... I've been so torn about how to implement so many of these things. I've had a lot of people ask me about that particular issue, and when I tell them the original markdown behavior requires 2 newlines after a line before starting a list, it was the last thing they expected. The main problem with markdown is not the fact that these counterintuitive things exist, but the fact that they're not consistently implemented. I've spent nearly 2 years trying to reconcile all these differences. See https://github.com/chjj/marked https://github.com/chjj/marked for more crazy markdown nonsense in the test suite.

Tobu 13y ago
Next time people ask, just explain that markdown always reflows consecutive lines. GitHub's change (for comment fields only) isn't list specific, they just never reflow. They document it here: https://help.github.com/articles/github-flavored-markdown#newlines https://help.github.com/articles/github-flavored-markdown#ne...
- chjj 13y ago
 Having newlines=line-breaks does not necessitate what I mentioned above. This is actually a common issue across multiple markdown engines, including ones that do not implement github's newline behavior. I suppose you can think of it that way logically, but I don't consider this a part of GFM since it is actually so easily mistakenly implemented. It is list-specific. If I did agree with you on this, I could edit my post and change "github" to any of a dozen markdown implementations that supposedly implement markdown accurately and it would be just as true. But, like I said, GFM could obey the markdown spec with respect to the list and still obey its own spec. To explain this concept: Why doesn't Four + Five + Six Simply yield Four + Five + Six And instead yields Four<ul><li>Five</li><li>Six</li></ul> It mistakenly thinks that line is a list - that is the bug, not the newline behavior. You could have both behaviors at the same time without conflict. It could return the first output and still be true to the newline part of the GFM spec as well as the original markdown. Instead, it chooses to do something ridiculous.
 - Tobu 13y ago
 The spec deviation for newlines could be done in multiple ways, but the implementations you mention all choose to trigger block constructs (which includes lists, and also headings) on any start of line. It's because the syntax tweak is intended to avoid confusing people with context-dependent syntax (syntax appears not to work if there wasn't an empty line before), not to give an alternative way to generate <pre>.

by chjj 13y ago

Tobu 13y ago

Next time people ask, just explain that markdown always reflows consecutive lines. GitHub's change (for comment fields only) isn't list specific, they just never reflow. They document it here: https://help.github.com/articles/github-flavored-markdown#newlines https://help.github.com/articles/github-flavored-markdown#ne...

chjj 13y ago
Having newlines=line-breaks does not necessitate what I mentioned above. This is actually a common issue across multiple markdown engines, including ones that do not implement github's newline behavior. I suppose you can think of it that way logically, but I don't consider this a part of GFM since it is actually so easily mistakenly implemented. It is list-specific. If I did agree with you on this, I could edit my post and change "github" to any of a dozen markdown implementations that supposedly implement markdown accurately and it would be just as true. But, like I said, GFM could obey the markdown spec with respect to the list and still obey its own spec. To explain this concept: Why doesn't Four + Five + Six Simply yield Four + Five + Six And instead yields Four<ul><li>Five</li><li>Six</li></ul> It mistakenly thinks that line is a list - that is the bug, not the newline behavior. You could have both behaviors at the same time without conflict. It could return the first output and still be true to the newline part of the GFM spec as well as the original markdown. Instead, it chooses to do something ridiculous.
- Tobu 13y ago
 The spec deviation for newlines could be done in multiple ways, but the implementations you mention all choose to trigger block constructs (which includes lists, and also headings) on any start of line. It's because the syntax tweak is intended to avoid confusing people with context-dependent syntax (syntax appears not to work if there wasn't an empty line before), not to give an alternative way to generate <pre>.