The behaviour seems odd to me, and the result is complete different in commonmark.js compared to others like markdown.pl and GFM. But I am having trouble working out whether that is due to a bug in commonmark.js, or whether I am just not understanding the spec properly.
Based on the text above examples 197 and 213, I would have expected Sample 1 to be rendered
since none of the lines is indented enough to become a sublist. The “four” line is being treated as a continuation. But I am not sure why that is the case.
So, is this a bug, or a spec issue, or BKAC issue?
If you read the spec on lists, you’ll see why this gives you the
behavior it does with the reference implementations.
Block-level content inside list items (including other lists) need to be
indented past the list marker. In this case the marker is two
characters wide, so you need at least two spaces indent (not just one)
to get a sublist. For bullet lists, the marker is one space wide, so
one space indent suffices.
OK, I see what is going on here. In lib/blocks.js, around lines 384-399, the parser assumes that if a line is indented 4 or more spaces but it’s not a code block (because it would be interrupting a paragraph), then it’s a lazy paragraph continuation. That assumption is wrong, because it might be a list item.
I do think the new behavior is more intuitive, but I’m still struggling to understand the spec. I looked at the implementation, and see it’s based on whether a line can be lazily continued, but I’m not yet 100% convinced this is the correct formulation. For one, making the list loose brings you back to interpreting the inner indents as a code block. Simple test case:
So I definitely don’t feel that the spec language precisely specifies what an implementation should do at this point.
(Incidentally, my implementation is now open-source and it’s possible to play with it: pulldown-cmark. This case is currently the only test that’s failing)