Respect indent when parsing Org bullet lists #1680
Conversation
Fixes issue with top-level bullet list parsing. Previously we would use `many1 spaceChars` rather than respecting the list's indent level. We also permitted `*` bullets on unindented lists, which should unambiguously parse as `header 1`. Combined, this meant headers at a different indent level were being unwittingly slurped into preceding bullet lists, as per Issue jgm#1650.
|
Good catch and nice patch, thanks. I didn't get to test it yet, but it looks good. Some minor nitpicking: List starts are now parsed with multiple functions, allowed bullet-point characters are defined in three places. This isn't a big deal here, but it breaks the “single point of truth” principle. While being more verbose, it would (IMHO) be clearer to define a named constant containing the allowed characters (and to |
|
I'll try and tidy up the constants later tonight. Not sure what to do about the double-parse of list starts. My first attempt was to change the definition of 'list continuation' to include things at the same indent level, but it required more surgery than I had time for. |
|
@jgm: +1 from me for this PR |
Respect indent when parsing Org bullet lists
Fixes issue with top-level bullet list parsing in Org reader. Indent level
now matters.
Previously we would use
many1 spaceCharsrather than respectingthe list's indent level. We also permitted
*bullets on unindentedlists, which should unambiguously parse as
header 1.Combined, this meant headers at 0-indent were
being unwittingly slurped into unambiguous preceding bullet lists, as per
Issue #1650.