seemingly no good way to end bulleted list and start code block

[Waylan Limberg]

On 10/6/07, John MacFarlane <jgm at berkeley.edu> wrote:

> > So I'm seriously thinking about adding a second (unindented) code block

> > syntax to PHP Markdown Extra that would avoid this issue entirely.

> > Something like this:

> >

> >     Regular paragraph

> >

> >     ~~~

> >     Code block

> >     ~~~

>

> I like the idea of doing something about this problem.  I've been

> thinking about adding something like this to pandoc, too, and it

> would be good if possible to reach some agreement on a syntax.

>

> If I recall, in the previous thread there were two suggestions for

> solving the problem:

>

> 1.  adding delimited unindented code blocks, along the lines of

>     what you suggested above

>

> 2.  adopting the convention that two blank lines end a list (or

>     footnote or other block element in which indentation is used

>     to indicate continuation blocks).


Ah, you beat me to it. This is my prefered solution.


>

> Do people have views about the comparative advantages and disadvantages

> of these approaches?

>

> An advantage of (2) is that it provides a clean way to have two

> consecutive lists of the same type.

>

> An advantage of (1) is that it allows you to cut and paste code without

> adding or removing indentation. It's also something that you see quite

> often in emails, and thus goes along with markdown's general philosophy

> of using established conventions.

>

> However, I prefer ======== to ~~~~~~~~~~ for this purpose, because

> ====== is vertically centered on the line and gives you a more

> symmetrical look. Compare:

>

> ~~~~~~~~~

> example 1

> ~~~~~~~~~

>

> =========

> example 2

> =========

>

> As long as a blank line is required before the string of ======='s,

> there is no danger of confusing this with a Setext-style header.


Well, except when the second to last line of the code block is blank:

===========
some code

this looks like a header
===========

Granted, 'true' parsers and state machines shouldn't choke on this,
but some of the implementations that rely on regex may without jumpimg
through hoops. Besides, the tildes look plenty symetrical in the
machine I'n currently using with the type face I'm currently using. Of
course, YMMV.

>

> John

>

> _______________________________________________

> Markdown-Discuss mailing list

> Markdown-Discuss at six.pairlist.net

> http://six.pairlist.net/mailman/listinfo/markdown-discuss

>



-- 
----
Waylan Limberg
waylan at gmail.com