Minor regexp oversight for setext headings

[Allan Odgaard]

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  
<p>”-rule.


> 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?),  
and
  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.