Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Nested lists require 4 spaces of indent #3
This issue is copied from Ticket 64 of our old bug tracker. It has been copied as-is:
If you wan this you can do:
This will work just fine. Of course, you will also need to use 2 spaces for indenting code blocks and everything else. The thing is, the entire parser relies on this variable being set. We can't use one figure some places and other other places.
I'm closing this WONTFIX.
This is very unfortunate. As written in this issue, 2 spaces are assumed to be the standard for nested lists (e.g. github does that; but the markdown syntax description leaves this open), 4 spaces for code blocks.
As #364 shows, this confuses many people. I didn't expect that all - I thought nested lists were simply not working, or I needed an empty line between indentation levels or I couldn't mix
If it's not possible to do this in the parser, I consider this a parser bug.
As a short term workaround, the
Python-Markdown's behavior is _NOT_ a bug (and not up for debate). As I clearly state in #364:
The word "must" leaves no room for interpretation. To require anything less that 4 spaces _is a bug_. In fact, for years now, this position has been stated in our documentation.
Yes, this means that almost all other implementations contain a bug. However, I am not going to copy that bug into my implementation. It is a bug. Why would I do that? So yes, it is unfortunate... that all the other implementations implement this bug. Perhaps they should stop (for the record, I know why they don't but that is a different discussion).
And while GitHub may be popular, their Markdown implementation is probably one of the farthest from the rules IMO. In the past when I reported a difference between the standard and their behavior, their response was that they didn't care what Markdown does, they were going to do their own thing anyway. So, please don't ever suggest that I should follow GitHub's lead in how to interpret Markdown text. If anything, I would suggest that GitHub stop calling their implementation Markdown.
But, hey, everyone is entitled to their own opinion. If you disagree with me, go create your own extension which implements lists as you want them to work. We provide the API so you can do anything you want. In fact, the Sane Lists extension provides an alternative list parser (which addresses a different issue with lists). No reason why one couldn't exist which implements this bug everyone keeps requesting.