text/markdown effort in IETF (invite)

Fletcher T. Penney fletcher at fletcherpenney.net
Thu Jul 10 12:27:14 EDT 2014


This isn't entirely true.  For example, try to insert a list immediately 
preceding an indented (not fenced) code block, where the code block is 
*not* part of the list.  By doing so, you convert the code block into a 
paragraph that becomes part of the last list item.  Indenting with one 
more tab results in a code block, but that code block is still part of 
the list.  This seems to be one of the first "gotchas" that gets many 
new users to Markdown.

I suppose it's debatable as to how "non-local" that effect is 
considered, since the code block immediately follows the list.  But 
inserting one structure (the list) breaks something that previously 
worked (the code block).

A less debatable example is fenced code blocks (not part of Markdown per 
se, but part of many derivatives.)  I was reluctant to include fenced 
code blocks in MultiMarkdown for just this reason.  To my chagrin, after 
adding fenced code block support to MMD, I then realized just how much 
of a bad idea they are.  They are the one syntax element you can't 
identify by simply looking local to that portion of the text.  You have 
to start all the way at the beginning, which can be a headache if you 
have a novel contained in a single text file.


Consider the following excerpt from a document:

	```

	This is *text*
	
	```
	
	This is more *text*
	
	```

Without knowing the entire document before the "snippet", one cannot 
determine which of those sentences is a code block, and which is a 
paragraph.  The first row of single quotes could be starting a new code 
block, or it could be closing a previous code block.  One accidental 
fence delimiter at the beginning of a document could alter the meaning 
of the entire thing.  It's basically an "even/odd" problem, and the only 
way to know if a particular fence is even or odd is to count all the 
preceding fences.

This may not really matter that much when a single person creates a 
single document to be converted once into a single web page.  But in 
more complicated real world use, this can be problematic.

I don't know that there is much to do about it at the moment, and I 
don't currently plan to yank fenced code blocks from MMD.  But I mention 
it so that it can be considered when proposing additional new features 
on top of the Markdown base set.


FTP


On 7/10/14, 9:30 AM, Aristotle Pagaltzis wrote:
> I’m afraid you entirely misunderstood what I meant by non-local.
>
> What I was referring to is, e.g. in HTML you can insert tags at the top
> of a document such as `<table>` or `<pre>` which then change the way the
> entire remaining document is to be rendered. They affect the document
> non-locally.
>
> Markdown does not have such constructs. If you include a Markdown Extra
> table in the document and you put that document through Markdown.pl, you
> will get a garbled form of the source of the table syntax as output for
> the table, but the misrendering is only local. The rest of the document
> will be unaffected and will render correctly.

-- 
Fletcher T. Penney
fletcher at fletcherpenney.net


More information about the Markdown-Discuss mailing list