Feature request: ignore spaces before a list bullet (was: does not parse bullets very well)

[sdupuis1]

Seems to have issues with spacing
Ex. does not work:
Draw a large face of a clock and place in the numbers \n\n + position the hands for 5 minutes after 11 o'clock \n\n + On your clock, label "L" for the long hand and "S" for the short hand

removing the spaces before the + makes it work. P.S. this should be some text followed by 2 bullet points.

Also had issues when using a * for bullet points.dot have an example handy but it seems to confuse it with emphasis which is also a *

[laptobbe]

Hi @sdupuis1

I don't fully understand your problem from your description. Could you share an example of the markdown you are trying to parse and what you expect the result to be.

[sdupuis1]

Draw a large face of a clock and place in the numbers \n\n + position the hands for 5 minutes after 11 o'clock \n\n + On your clock, label "L" for the long hand and "S" for the short hand

[sdupuis1]

The below markdown works(note the difference):
Draw a large face of a clock and place in the numbers \n\n+ position the hands for 5 minutes after 11 o'clock \n\n+ On your clock, label "L" for the long hand and "S" for the short hand

[laptobbe]

I see the '+' has to be the first char on the line for a list to work. Is this a problem for you? This is usually how you define a list. If you have a suggestion on an improvement on the regex I am happy to merge it. Unfortunately I don't have time to look into this problem right now.

[sdupuis1]

Add it to your list :) The reason you would want this is if the markdown had a list, then sublist. This is typically done with some space indentation. Thx for at least looking :) I think I may fork you project and add some things.

[Coeur]

Note that 4 spaces before a '+' sign could be interpreted as a code block in some popular Markdown implementations. So implementing this feature should not allow for an arbitrary number of spaces.

[Coeur]

Sublists with spaces (like here on github) are something contextual and might be tricky to parse using regex. See https://en.wikipedia.org/wiki/Chomsky_hierarchy. But then, some NSRegularExpressionAnchorsMatchLines together with look-ahead syntax might help to achieve it.

But I'm concerned with the ambiguity of sublist and code block. I would prefer a multi-sign syntax (like mediaWiki) to a multi-space syntax (like commonmark).

Multi-sign-style:
+ top-level
++ sub-level

This would also be coherent with header multi-sign syntax.