Nested ordered list numbering

[vas]

@floda

I suppose this mouthful is the cause:

In order to solve of unwanted lists in paragraphs with hard-wrapped numerals, we allow only lists starting with 1 to interrupt paragraphs.

That’s because there’s a typo. It was reported and fixed just yesterday. But even with the typo in that paragraph, if you read the entire section on Lists (which I linked in my previous reply), focusing especially on the examples, are you still confused?

@floda

It’s getting especially confusing when you use multiple different applications, as everything parses just differently enough to wreak havoc.

That’s pretty much the impetus for creating CommonMark in the first place. You will avoid such issues if you stick to CommonMark compliant tools, ones that promise 100% spec compliance, and when they diverge, you should file a bug and/or switch tools.

Whenever you have doubts about whether you or the tool is wrong about the syntax, I recommend use BabelMark 2 or BabelMark 3 to see what well known parsers have to say. For example, the results for your list use case has:

• a group of tools that agree with your expectations that 3. three is a list item, but don’t agree that it continues the earlier sublist, numbering it 1 instead of 3. This group includes the original Markdown.pl, others that were dominant before the rise of CommonMark and GFM, and also Pandoc(strict).
• a group of tools that are CommonMark compliant, that don’t see 3. three as a list item.
• very small group that agrees with your expectations, a list item that starts with 3. This includes Pandoc (non-strict).

@floda

It’s funny how a simple markup idea supposed to make things easier had me invest many hours just to keep my notes from exploding.

If what you mean is that different tools follow different rules, yes, that has costs. But if what you mean is that the idea behind Markdown hasn’t made things easier, I don’t agree. You have to think about what “simple” means. If it means, “The markup must be simple, but must also be able to correctly interpret ambiguity-laden corner cases”, then that is impossible without artificial intelligence. Looking at the examples in the List section of the spec, how is a dumb machine supposed to know that 14. The number of doors is 6. is not a list item?

But if what you mean by “simple” is:

A syntax which the user can grasp after reading a short description, and which the vast majority of users can use without issue 99 or even 99.9% of the time, without ever having to read much less internalize all the possibly esoteric rules the syntax may incorporate, especially when those esoteric rules are designed precisely so that the vast majority of users can it use without issue 99 or even 99.9% of the time.

…then I think that Markdown has been very successful, and the proof is in the pudding.

It’s important to realize that your list use case is very very rare. I doubt even one out of a thousand users have sublists that continue across parent list boundaries. For users with different needs, that want a syntax that has the precise control of code rather than natural language, there are syntaxes for that, e.g. HTML or Asciidoc.

*(btw, the reason I take the time to write extensive replies like this on this forum is because I’m working on a proposed evolutionary step for structured plain text. Hearing people’s issues and writing replies helps me think and keeps me grounded