Minor regexp oversight for setext headings

Allan Odgaard 29mtuz102 at sneakemail.com
Sun Oct 8 14:44:16 EDT 2006

On 8. Oct 2006, at 19:24, John Gruber wrote:

> I feel strongly now that this was a mistake, and that the rules

> should be tightened such that all (or nearly all -- there may be

> worthwhile exceptions I haven't considered) block level constructs

> must be both preceded and succeeded by a blank line. (Or they must

> occur at the start or end of the document, of course.)

The inconsistency is bad, I agree :) As you hopefully saw, I sent a
list to the OLPC list about the inconsistencies as I see them, and my
proposed changes.

As for requiring a blank line below the block level element: you sort
of already have that requirement due to lazy mode. I personally do
not like the lazy mode for embedded stuff though, for example take
this (previously mentioned) example:

> > Someone wrote something
> And someone else replied

Variations of this frequently appears in emails, and as we base email
syntax highlighting in TextMate on the Markdown language grammar, we
deliberately changed the rules here, which did trip at least one user
-- so I would really like to see this changed in Markdown as well.
And given how lazy-mode fails (produces broken HTML) for half the
examples with embedded block level content, I anyway do not see the
value of it.

As for requiring a blank line above, except when at the start of the
document, or, I guess, being the first embedded item in a block level
context (like starting a block quote with a list item), the only
thing which springs to mind as then being problematic is, if I want
to write a list of short items where one of the items embeds a block
level elements, for example:

* you can do this
* or you can do that
* but don’t do any of the following:
1. foo
2. bar

The problem with the new requirement is that adding this extra blank
line makes the third list item have its text wrapped in <p> -- this
however is more a problem with the “when are list items wrapped in

> I'm unsure whether I should change to rules to allow for hard-

> wrapped lines in Setext headers. [...]

I would vote no to that. Mainly because:

a) I don’t see when it is useful,
b) I don’t think the plain text version is clear (is it a wrapped
heading, heading with a sub-heading, or paragraph with a separator?),
c) it makes it slightly more complex to parse them, for example
currently I can: grep '^==*' -B1 to extract all level 1 headings from
a document.

More information about the Markdown-Discuss mailing list