Nested lists don't work in markdown #137
Comments
ghost
assigned 
|
Nested lists need to be indented four spaces or a tab. This is implied by the markdown Google Code Info: |
|
It is implied by the markdown syntax documentation? Where? John Gruber's But good to know it works somehow. :) Google Code Info: |
|
What's explicit in the markdown syntax description is that continuation paragraphs It's true that Markdown.pl allows less than four-space indentation, but its treatment
Here's you'd expect three levels of nesting, but you only get two. There are other You might ask: why not just consistently make any additional indentation start a
Here the numbers don't line up in the same column on the left, but we want them to Anyway, this has been discussed at times on markdown-discuss, and no clear Google Code Info: |
|
Thank you for the thorough response. It does not surprise me that even Gruber's Awesome project, btw. Google Code Info: |
|
I was just struggling with nested lists a bit and upon Googling, came across this resolved issue and the comment I liked above from @jgm was the answer for me. I think https://guides.github.com/features/mastering-markdown/ should be updated to say indentation should be 4 spaces or a tab. Also, the examples for nested lists use 2 spaces in the Lists example, but the Lists section on the page shows 3 spaces. These should both probably use 4 spaces to further clarify. Thanks! |
|
@mhbrown - yes, absolutely. The advice in the "mastering markdown" page you link to is very bad. The only safe advice that will work reliably across all Markdown implementations is to use a 4-space indent. A 2-space indent See http://johnmacfarlane.net/babelmark2/?normalize=1&text=+-+a%0A+++-+b%0A+++++-+c%0A+++++++-+d%0A for an illustration. The situation is even worse for ordered lists: http://johnmacfarlane.net/babelmark2/?normalize=1&text=+1.+a%0A+++2.+b%0A+++++3.+c%0A+++++++4.+d%0A. Only one implementation (not the one GitHub uses) consistently honors a 2-space indent. Please give feedback to GitHub to change their misleading guide. |
LaTeX template: add babel-otherlangs and babel-newcommands
Closes #3511. Previously pandoc used the four-space rule: continuation paragraphs, sublists, and other block level content had to be indented 4 spaces. Now the indentation required is determined by the first line of the list item: to be included in the list item, blocks must be indented to the level of the first non-space content after the list marker. Exception: if are 5 or more spaces after the list marker, then the content is interpreted as an indented code block, and continuation paragraphs must be indented two spaces beyond the end of the list marker. See the CommonMark spec for more details and examples. Documents that adhere to the four-space rule should, in most cases, be parsed the same way by the new rules. Here are some examples of texts that will be parsed differently: - a - b will be parsed as a list item with a sublist; under the four-space rule, it would be a list with two items. - a code Here we have an indented code block under the list item, even though it is only indented six spaces from the margin, because it is four spaces past the point where a continuation paragraph could begin. With the four-space rule, this would be a regular paragraph rather than a code block. - a code Here the code block will start with two spaces, whereas under the four-space rule, it would start with `code`. With the four-space rule, indented code under a list item always must be indented eight spaces from the margin, while the new rules require only that it be indented four spaces from the beginning of the first non-space text after the list marker (here, `a`). This change was motivated by a slew of bug reports from people who expected lists to work differently (#3125, #2367, #2575, #2210, #1990, #1137, #744, #172, #137, #128) and by the growing prevalance of CommonMark (now used by GitHub, for example). Users who want to use the old rules can select the `four_space_rule` extension. * Added `four_space_rule` extension. * Added `Ext_four_space_rule` to `Extensions`. * `Parsing` now exports `gobbleAtMostSpaces`, and the type of `gobbleSpaces` has been changed so that a `ReaderOptions` parameter is not needed.
What steps will reproduce the problem?
{{{
}}}
What is the expected output? What do you see instead?
The output is not a nested list. The nested element appears at the same
level as the other elements.
What version of the product are you using? On what operating system?
1.4 on windows.
Google Code Info:
Issue #: 229
Author: paul.chi...@gmail.com
Created On: 2010-04-01T15:19:28.000Z
Closed On: 2010-04-01T22:46:16.000Z
The text was updated successfully, but these errors were encountered: