definition lists containing multi-paragraph ordered lists rendered as code

[aronatkins]

Given Markdown with a definition list that contains an ordered list and the ordered list has multi-paragraph elements, each ordered list element is rendered as a separate ordered list and the paragraphs are rendered as code blocks.

This appears specific to definition lists (using def_list). It does not appear that other types of lists make a similar formatting decision for multi-paragraph sub-lists.

The markdown input:

term

:   this is a definition for term. it has 
    multiple lines in the first paragraph.

    1.  first thing
    
        first thing details in a second paragraph.
        
    1.  second thing

        second thing details in a second paragraph.

    1.  third thing

        third thing details in a second paragraph.

Expected:

<dl>
<dt>term</dt>
<dd>
<p>this is a definition for term. it has
multiple lines in the first paragraph.</p>

<ol>
<li>first thing
<p>first thing details in a second paragraph.</p>
</li>

<li>second thing
<p>second thing details in a second paragraph.</p>
</li>

<li>third thing
<p>third thing details in a second paragraph.</p>
</li>
</ol>

</dd>
</dl>

Actual:

<dl>
<dt>term</dt>
<dd>
<p>this is a definition for term. it has
multiple lines in the first paragraph.</p>
<ol>
<li>first thing</li>
</ol>
<pre><code>first thing details in a second paragraph.
</code></pre>
<ol>
<li>second thing</li>
</ol>
<pre><code>second thing details in a second paragraph.
</code></pre>
<ol>
<li>third thing</li>
</ol>
<pre><code>third thing details in a second paragraph.
</code></pre>
</dd>
</dl>

Tested with:

/usr/local/bin/markdown_py -x def_list definitions.md
/usr/local/bin/markdown_py --version
# => markdown_py 3.2.1

[waylan]

Thanks for the report.

This could be a tricky one to fix. I believe the issue is related to the DefListIndentProcessor, which subclasses the ListIndentProcessor and overrides the LIST_TYPES variable by replacing ['ul', 'ol'] with ['dl']. That attribute is relevant for parsing lose lists. When the parser finds an indented block which could be a nested list item, it checks the previously processed block. If the previous block is one of the types in LIST_TYPES, then is prosesses the current block as a child of the previous block.

The problem here is that the second level of nesting is a ol item, but it sees that the last item is a dl, so it doesn't match. I suppose instead it needs to recognize the extra level of nesting and look at the last child of the dd in the dl. The problem is that that needs to happen in ListIndentProcessor rather than the DefListIndentProcessor, which means the def_list extension also needs to override the builtin list parsing.

Alternatively, the entire block parser could be refactored to consume all nested content as a single block, rather than processing each individual sub-block separately. But that would be a major change and isn't likely to happen anytime soon.

[aronatkins]

@waylan Thanks for digging and confirming. The ambiguity of four-space indents certainly isn't helping. Is it an indented code block? Maybe. Is it a secondary paragraph of a list item? Maybe!

I've restructured our documentation to avoid this problem - the ol beneath dd no longer contains multiple paragraphs in list-elements. Advice? Keep description details (dd) simple!

[RokeJulianLockhart]

Alternatively, the entire block parser could be refactored to consume all nested content as a single block, rather than processing each individual sub-block separately. But that would be a major change and isn't likely to happen anytime soon.

Does this now work? I ask because I've yet to locate a parser which copes with multi-line block elements nested inside a DL.

[facelessuser]

This issue was closed with fixes for the specified issues. Do you have a scenario that doesn't work? If so, please open a new issue.