Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I found this problem when I tried to parse a list inside of a blockquote:
"> * a\n> * b"
gets parsed to"<blockquote><p><ul><li>a<ul><li>b</li></ul></li></ul></p></blockquote>"
(the second bullet is incorrectly nested an extra level).The problem was not with lists inside blockquotes exactly. The previous implementation relied on the first indent in lists never having white-space between it and the blockquote character. The markdown editor I used (typora) always includes a whitespace between the ">" and the "*" characters (which is not unusual behavior for markdown editors). The problem persists without the blockquote character:
" * a\n * b"
gets parsed to"<ul><li>a<ul><li>b</li></ul></li></ul>"
I believe this is undesired behavior because several other markdown parsers I've found (including the on I'm writing this PR in) all parse
"* a\n* b"
(0-spaces)," * a\n * b"
(1-space), and" * a\n * b"
(2-spaces) into"<ul><li>a</li><li>b</li></ul>"
. Plus it just makes sense.This bug is a result of trimming the first lines of lists. The first line, because it's trimmed of its white-space, is read has having an indent of zero and the second line an indent of 1, so the parser sees this as a further indentation when really we want both lines to be at the same level of nesting. The code is already written such that nothing actually conditions on the first indentation level of a list being denoted as 0, so by simply not trimming the first line in a list we can have the desired behavior.
The test case I changed was failing because the parser registered starting at 1 space, then unindenting to 0 spaces, but the transformer state had nothing in
:lists
and there was a null pointer error. This seems like an error with the test case that was only revealed upon fixing the indenting bug.