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