Repository navigation
Conversation
A list item which directly followed an indented paragraph or nested list of the previous item, without a blank line between them, was treated as a lazy continuation line of that block (Python-Markdown#845). `ListIndentProcessor` now splits the block before the first unindented line which starts another item of the list. The registered list processors decide what counts as an item, so `sane_lists` still treats a marker of the other list type as text. Other unindented lines remain lazy continuations. As no blank line comes before them, the split off items continue the list as tight items: a `listcontinue` parser state tells `OListProcessor` not to make the first of them loose. They are parsed like any list block at that level, so a horizontal rule or header after them now ends the list, as it already does at the top level. Fixes Python-Markdown#845.
| ) | ||
|
|
||
| # With `sane_lists`, a marker of the other list type does not start an item. | ||
| def test_other_list_type_after_indented_paragraph_sane_lists(self): |
There was a problem hiding this comment.
This test is for the sane-list extension and therefore should be at tests/test_syntax/extensions/sane_lists.py Apparently all of our existing tests are in the old format at tests/extensions/sane_lists.txt. They could be refactored into the new format, but that it not necessary if they do not need to be edited.
There was a problem hiding this comment.
Moved it and also added the test_ prefix so the test runner picks it up like the other files there
Just saw that. It should definitely be covered at the same time. |
I believe this issue was generally known; at least I was aware of it. Due to the fact that I rarely run into it, I think it was never a priority for me to look into 🤷🏻. |
An item of a nested list which directly follows an indented paragraph of the previous nested item, without a blank line, was still merged into that paragraph. Split an indented block at the first line which is indented less than the block and starts an item of the list at that level of indentation, not only at unindented lines. When the rest is still indented, it is split again in the same way, and its items continue the nested list as tight items, as at the top level. Also move the sane_lists test to a test file for the extension. Refs Python-Markdown#845.
5842d7c to
1826557
Compare
|
Thanks for the review |
3 participants
Description
Fixes #845.
When a list item comes right after an indented paragraph or nested list of the previous item, with no blank line in between, it was swallowed into that paragraph as a lazy continuation line.
ListIndentProcessornow ends the indented block at the first line that is indented less than the block and starts another item of the list at that level, so it works at any level of nesting. Those items continue their list as tight items, because no blank line comes before them (the same as Markdown.pl).Unchanged:
First line of a paragraph/- second lineexample from the issue.sane_lists, a marker of the other list type is still treated as text.One behaviour change: a horizontal rule or header right after those items now ends the list, the same as it already does for a list at the top level. Before, it ended up inside the previous item.
Not covered: the equivalent case with
def_list, where a:definition comes right after an indented paragraph of the previous definition. I'm happy to look at that separately.AI Assistance Disclosure
No AI tools were used in preparing this PR.
AI tools were used and I have disclosed which ones, and have fully reviewed and verified their output.
AI tools were use to assist with the following:
Checklist