[ANN] vfmd

Michel Fortin michel.fortin at michelf.ca
Wed Oct 2 13:00:17 EDT 2013

Le 2-oct.-2013 à 11:49, Roopesh Chander <roop at forwardbias.in> a écrit :

> Unless the complexity increases by several orders of magnitude, I would

> think that it's better to have a parser that gives a more correct

> interpretation, even if it's at the expense of a little higher complexity

> of programming.

Anything that is more complex has ripple effects through the test suite (which has more code paths to check) and to the edge cases we need to think about when factoring the spec. One you probably didn't think of:

> still blockquote
>\tblockquote or code block?
> \tblockquote or code block?


Also, while you might care only about vanilla Markdown in the spec, assuming I decide to rewrite the parser to match this spec *I* will have to care about my Markdown Extra extension, and other implementers will have to care about their own extensions, which are going to add many more cases to care about. Definition lists, footnotes, markdown="1", fenced code blocks all have to care about indentation to a certain degree. The more the spec deviates from what the parsers are actually doing, the more difficult it'll be to adopt for implementers for two reasons: implementation work and the potential to break our user's documents.

Another thing to factor in:

- how many documents this new behaviour will break? (hard to know)
- how many people will benefit from the new rules? (is there any?)

If no one is inconvenienced by the current behaviour then I don't think it is reasonable burden implementers to change it, even for a theoretically better one.

Something which is available today and is easy to understand (and that PHP Markdown allows[^1], inherited from Markdown.pl) is to configure the tab length to something else, say 8 spaces. This could be useful if someone gives you a document written in a 8-space-per-tab editor. In this case, a tab represents two level of indentation instead of one. Even then, I've never heard of someone using the option.

[^1]: See the [parser configuration variables](<http://michelf.ca/projects/php-markdown/configuration/#markdown>)

Michel Fortin
michel.fortin at michelf.ca

More information about the Markdown-Discuss mailing list