Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
Nested lists are too picky about whitespace #368
Here's some Markdown markup:
Break. * Root level * Second level * Third level * Back to second level Break again. 1. Root level * Second level * Third level * Back to second level Final break. 1. Root level * Second level * Third level * Back to second level End of example.
The middle list should look like the last list.
See this gist for the same input with proper output: https://gist.github.com/chbrown/be1fd39b26da6022846d01d7b2ccfaa4
Thanks for showing this example!
There is actually a bug in kramdown concerning the parsing of the middle list:
So the output of the above should actually be:
<ol> <li>Root level * Second level <ul> <li>Third level</li> <li>Back to second level</li> </ul> </li> </ol>
Okay. So, to clarify for anyone else who stumbles on this issue:
My desired solution — kramdown not being so nitpicky about indentation — is a no-fix.
Instead, the bug here is that, as of my original post, the version of kramdown that GitHub was using to render Markdown in gists (etc.) was trying to parse the middle-nested list as a list, but it shouldn't have, since it wasn't indented enough. Anything not indented 'enough' should, according to the spec @gettalong linked to, be interpreted literally.
I'm still not clear why the "Back to second level" item stays in the same list as the "Third level" item, but the parser has already diverged by that point from what I was intending with the three levels, so perhaps whatever it's trying to do there is outside the scope of needing rationalization.
kramdown is not "nitpicky", it just tries to follow a sensible specification. Try using other Markdown parsers and you will get many different behaviours, with many edge cases and cases where you can't tell from the source code what the output will be.
As for Github gists: They use a different Markdown dialect, not kramdown, for gists, so yes, the behaviour will differ in many cases. There is no Markdown spec.
As for the problem at hand, I have to apologize since it seems that some experimental code came into play when I tested - so the problem still needs to be fixed for the next release. I'm sorry for mixup!
You're right; a lot (
Which is why I can get away with arbitrary prescriptive judgments like 'nitpicky'
I have looked at the issue in more detail now and there was another problem with the behaviour of the "Back to second level" item. So kramdown will now output the following:
<ol> <li>Root level * Second level <ul> <li>Third level * Back to second level</li> </ul> </li> </ol>
Note that the output will be different when using the GFM parser if the option "gfm_quirks" includes "paragraph_end" which is the default!
Hi there! I was emailing with GitHub support yesterday about some list differences I was seeing:
And they pointed me to the following being the reason for the difference:
Which after going searching and finding: http://spec.commonmark.org seems counter to the comment above:
Is moving in the direction of that spec anything that you / the Kramdown team would be interested in?
@IanLee1521 As I said, there really is no Markdown spec. I could also point you to the kramdown specification at http://kramdown.gettalong.org/syntax.html and ask you to change the Markdown parsers so that they comply with this spec.
The only advantage CommonMark has is that it has the word "Common" in its name, leading to the believe that it is a standard. It certainly may become one but currently, as I see it, it is not.
Also, I haven't yet seen any advantage of the CommonMark format in comparison to the kramdown format but I have to admit that I haven't checked for a while.
And a last point: There is no need for kramdown to move into the CommonMark direction. If you want to use CommonMark, just use a CommonMark parser