Here’s a nice case:
Here is a summary of the different approaches different implementations take:
Treat this exactly as if it’s expanded to spaces, that is, as equivalent to
>+ 7 spaces +
x. In this case the first space is gobbled up as an optional space after
>, the next 4 are treated as indentation for a code block, and we get a code block with two leading spaces.
Treat this as if it’s expanded to spaces, but don’t treat the first space as an optional space after
>. Then we get a code block with three leading spaces.
Treat the first tab as an optional space character after
>, and the second tab as the indentation of a code block. Then we get a code block with just
x, with no leading spaces.
Don’t treat the first tab as an optional space character. Treat it as code block indentation, leaving the second tab as part of the code block contents. Then we get a code block with a leading tab.
Now that we’re allowing tabs in code blocks, I find the first two approaches strange. After all, there are no spaces in the Markdown source – only tabs – so why should the code block contain spaces, which aren’t there? (This made more sense when we converted all tabs to spaces before parsing.)
I’m somewhat inclined to favor the 4th approach, but I fear that it might break some existing documents, making regular block quotes into quoted code blocks. So maybe the 3rd approach is best overall.
There is a related issue about lists. How, exactly, do we calculate padding when the list marker is followed by a tab? If we pretend we’re converted tabs to spaces here, we’ll again get code blocks that have spaces when there’s none in the text.
Note that this looks like a bug; this should contain a code block of some kind. But I need to get clearer on the spec before this can be fixed.