Multi-paragraph list items don't (always?) work, example inside

[ell1e]

This is accepted by most other major markdown renderers I have tried, but python markdown doesn't seem to like multiple paragraphs in a list item - at least not indented like here:

Input:

* abcd.
  this is paragraph 1.

  efgh

* blubb

Expected output (Github):

• abcd.
  this is paragraph 1.

  efgh

• blubb

Actual output (python markdown):

>>> markdown.markdown("* abcd.\n  this is paragraph 1.\n\n  efgh\n\n* blubb")
'<ul>\n<li>abcd.\n  this is paragraph 1.</li>\n</ul>\n<p>efgh</p>\n<ul>\n<li>blubb</li>\n</ul>'
>>> 

(two separate <ul> lists, and efgh is not part of first list item as expected)

[facelessuser]

New paragraphs need to start with 4 spaces for the indentation. This is mentioned in the documentation.

[ell1e]

Consider it a feature request then. All other markdown libs (+that I have tried) support it like this, too, so why not python markdown? People writing markdown tend to do so intuitively, not matching an exact indent that might be documented in whatever spot, so I feel like this would be a great improvement for user friendliness.

[facelessuser]

Python Markdown is an old school parser. This question has been asked multiple times.

Python Markdown is also not alone either: https://johnmacfarlane.net/babelmark2/?normalize=1&text=*+abcd.%0A++this+is+paragraph+1.%0A%0A++efgh%0A%0A*+blubb. But yes, it is in the minority.

Anyways, @waylan (the maintainer) has mentioned before that there are no plans to change this behavior. I'll let him weigh in, but I imagine the stance is still the same

[waylan]

@facelessuser is correct. Based on a strict reading of the original rules, any other behavior is a bug IMO. If you want different behavior, then you are free to create your own extension.

[ell1e]

Is there an extension for this? Or any other python library for markdown that cares more about the end user expectations? (I also think how markdown has grown to be used, sticking religiously to specs isn't really in the spirit of the format, but that's just me.)

Edit: just to be more clear on that point,

Based on a strict reading of the original rules

I could be wrong, but my confident guess would be 99% of people using markdown don't know the "original rules" and likely prefer not to need to know what they are

[facelessuser]

Is there an extension for this? Or any other python library for markdown that cares more about the end user expectations? (I also think how markdown has grown to be used, sticking religiously to specs isn't really in the spirit of the format, but that's just me.)

There are a number of CommonMark and/or CommonMark-ish libraries, and some other various Markdown libraries available for Python. I do not have a list of what they are and what they can and cannot do. You are free to research them and find one that best suits you. I imagine a CommonMark(ish) library may have more consistency with what you are used to.

There are many libraries out there, all with slightly different quirks. Some libraries approached things a bit differently than maybe others. This is kind of why CommonMark came about. Some libraries out there may arguably be better than Python Markdown depending on what you are measuring by.

Python Markdown is not a CommonMark(ish) library but follows the admittedly loose, original spec. While I have never viewed Python Markdown's indentation requirement as a weakness, Python Markdown does have its share of weaknesses, but despite those weaknesses, the reason why I continue to use and contribute to Python Markdown is its ease of extendibility. I have valued that more than having a CommonMark(ish) library.

[ell1e]

This is kind of why CommonMark came about.

Thanks, this was a very useful hint! There appears to be a commonmark.py project, I will check that one out then. Thanks again

[alkisg]

I was just affected by this issue. I saw that github, gitlab etc were using - bullet when I clicked on the comments toolbar bullet button, and some sites like mkdocs-material was using two spaces as well, so I spent a few hours to adjust our documentation to use this consistently.

Then I bumped into a page that needed a fenced code block inside a bullet, and I searched and I found this issue; now I'll need to spend a few more hours to realign everything to four spaces!... :D

[alkisg]

Btw is there any way to use bulleted lists with 2 spaces, and then use 4 spaces indentation for whatever's inside them?
I wasn't able to make this work in python-markdown:

- bullet

      shell code

  How to continue the bullet?

It displays fine on github, the bullet (html li tag) can be continued properly:

• bullet

  shell code
  

  How to continue the bullet?

[waylan]

@alkisg whenever you are working with complex nesting I suggest you first structure the section of the document as if it was at the root level. Then, when you have that right, indent the entire section by one additional level. For you example, the final document should be as follows (with · used to represent spaces for clarity):

-···bullet

········shell code

····How to continue the bullet?

The extra two spaces on the first line are optional, but I prefer them as if keeps everything lined up. Remember, each level is four spaces. That means that any final level of indent must be divisible by four (6 is not).

Oh and for the record, "it works on GitHub" is not relevant because we are following a different set of rules (Markdown, not Commonmark).

[alkisg]

Thank you @waylan, this example cleared things up in my mind about the markdown levels.

we are following a different set of rules

I understand; but, C reached version C16 (2017), ECMAScript reached version 12 (2021) etc. In order to do that, they improved their specifications trying as much as they could not to break things. Maybe some similar things could happen with markdown whenever appropriate... if not, sure, that's understandable as well.