Incremental parser

Jacob Rus jacobolus at
Mon Sep 3 10:45:18 EDT 2007

Michel Fortin wrote:

> Allan Odgaard a écrit :

>> Michel Fortin wrote:

>>> [...] Take a look at this instead:


>>> int[1][2] one_by_two_array;


>>> Sure, a code block or span should be used here, but I think

>>> *requiring* the code block or span here in order to not screw up the

>>> end result isn't the right path to take [...]


>> You do realize that your example gets screwed up by Markdown even in

>> the current version, right?


> Yeah, and that was deliberate. I think the syntax is wrong in applying

> emphasis there, just as I think it would be wrong to put a link there

> unless there's an explicit link reference corresponding to the number.


> This works fine in PHP Markdown Extra, as it should.

Erm... wrong by what standard? This seems like an awfully fine line
you're walking here. Basically you're saying John Gruber's official
syntax description is "wrong" about intra-word emphasis, because you say
so (even though such a change undoubtedly breaks some existing markdown
documents, including some of mine incidentally), but "right" about
leaving [this][link] as plain text with a bunch of junky square brackets
in it, also because you say so, and because changing it would "screw up"
existing documents (it's not clear that any such documents exist).

Personally, I come down just the opposite way. The current spec for
intra-word emphasis is just fine by me, as I occasionally have use for
emphasizing part of a word, and words with underscores in them in any
document I've written with markdown belong in a raw block anyway, while
I consider leaving ugly square brackets in my prose to be "broken".

But frankly, these are rather rare edge cases, and the result isn't
deal-breakingly terrible either way for me. There are much more serious
examples of flaws in current Markdown, with some constructs rendered as
malformed HTML, for example.


More information about the Markdown-Discuss mailing list