Multiline code block within a list

[Waylan Limberg]

On Mon, Nov 7, 2011 at 7:01 PM, John MacFarlane <jgm at berkeley.edu> wrote:

> The alternate rule (described in my last email) seems equally reasonable to me,

> and the official markdown syntax description doesn't distinguish between

> them. (It never says explicitly that all spaces after the asterisk are

> ignored -- correct me if I'm wrong.)


The syntax rule states:


> List markers must be followed by one or more spaces or a tab.


"one or more spaces" is anything but clear. However, if does provide a
minimum but *not* a maximum. Taking that along with markdown.pl's
behavior indicates to me that all spaces up to the first non-space get
eaten/ignored - which means no code blocks in the first line of a list
item.

However, "a tab" limits to only one tab - which we all know equals
four spaces. So I suppose you could interpret that to mean that one to
four spaces get ignored and any more could count towards indentation.
But then we might use two tabs for indentation. But one asterisk plus
two tabs will offset the code from the remaining lines of the block
below it.

Or, as per your example, we need to special case 7 spaces. Any more or
less than 7 spaces and up to four get eaten? But when we only have 7
spaces, only eat 3? That sees more confusing. And what happens when we
have a numbered list? The dot and additional digits mess with the text
lining up even more. Do we now adjust the number of spaces required
for a code block for that? I doubt that would be a sensible solution.

Probably the most logical solution is to have fenced code blocks work
in list items. That's something I've been meaning to add to my todo
list for Python-Markdown. As elegant as indented code blocks are to
read, they just create too many headaches when writing. I find that
I'm using fenced code blocks almost exclusively these days. The one
limitation has been inside lists and blockquotes. Time to fix that.

-- 
----
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg