Collapsed Lists with headers fail to parse inline markup. about markdown

[waylan]

I suspect this is caused by the fact that the unprocessed text would be contained in the tail of the h3 element in ElementTree. The h3 is a block level tag and it is probably assumed to have no tail. Should be a somewhat simple fix.

However, a bigger problem may exist. Run the same sample input through markdown.pl and you do not get headers at all. The header syntax is ignored and the text passes through unaltered. For example:

<ul>
<li>### Promo Item 1 ####
Duis aute irure dolor in <em>reprehenderit</em> in voluptate velit esse cillum dolore eu fugiat nulla pariatur. <a href="http://www.naz.edu">Learn more</a></li>
<li>### Promo Item 2 ####
Duis aute irure dolor in reprehenderit in <strong>voluptate</strong> velit esse cillum dolore eu fugiat nulla pariatur. <a href="http://www.naz.edu" title="Yay">Learn more.</a></li>
<li>### Promo Item 3 ####
Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. <a href="http://www.naz.edu" title="Yay">Learn more.</a></li>
<li>### Promo Item 4 ####
Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. <a href="http://www.naz.edu" title="Yay">Learn more.</a></li>
</ul>

I believe this is probably the correct behavior. The source is a collapsed list (no spaces between items) which means there should be no block level elements contained within. If you have headers, then the remaining text should be paragraphs. Consider this input for comparison (note the blank lines between list items):

* ### Promo Item 1 ####
  Duis aute irure dolor in _reprehenderit_ in voluptate velit esse cillum dolore eu fugiat nulla pariatur. [Learn more](http://www.naz.edu)

* ### Promo Item 2 ####
  Duis aute irure dolor in reprehenderit in **voluptate** velit esse cillum dolore eu fugiat nulla pariatur. [Learn more.](http://www.naz.edu 'Yay')

* ### Promo Item 3 ####
  Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. [Learn more.](http://www.naz.edu 'Yay')

* ### Promo Item 4 ####
  Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. [Learn more.](http://www.naz.edu 'Yay')

Which outputs (from markdown.pl):

<ul>
<li><h3>Promo Item 1</h3>

<p>Duis aute irure dolor in <em>reprehenderit</em> in voluptate velit esse cillum dolore eu fugiat nulla pariatur. <a href="http://www.naz.edu">Learn more</a></p></li>
<li><h3>Promo Item 2</h3>

<p>Duis aute irure dolor in reprehenderit in <strong>voluptate</strong> velit esse cillum dolore eu fugiat nulla pariatur. <a href="http://www.naz.edu" title="Yay">Learn more.</a></p></li>
<li><h3>Promo Item 3</h3>

<p>Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. <a href="http://www.naz.edu" title="Yay">Learn more.</a></p></li>
<li><h3>Promo Item 4</h3>

<p>Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. <a href="http://www.naz.edu" title="Yay">Learn more.</a></p></li>
</ul>

I suspect our inline parser is assuming markdown.pl's behavior, but our blockparser doesn't execute on that behavior. So do we change the inline parser or the blockparser here?

[fvox13]

Hmmm... I think the reason I originally didn't put the space between list items was that, in older versions of Python-Markdown it was creating a separate ul for each of them. It looks like that has been fixed in the trunk of this product, so I'm cool with using the extra space between items.

As far as what to fix, I suppose this is a point where I disagree with Markdown.pl... from a usability standpoint, I don't see why lists should be parsed differently here. But I suppose the blockparser route would be the better one to take, if our goal is to be as close to Markdown.pl as possible.

[waylan]

Well, after looking at the code and comments It would appear that back when I rewrote the block parser I specifically chose the current behavior of Python-Markdown in this case. Therefore, I'm not going to bring it inline with markdown.pl at this time. I can see how markdown.pl's behavior could make sense to some degree (restrict to either all or no blocklevel elements in a list item), but it is certainly not the obvious behavior to the human eye when reading the source text. Guess I'll just fix the inline parser here. Besides, the inline parser should address this scenario regardless of what the block parser does. After all, third party extensions could create similar edge cases that the the inline parser needs to account for.