Le 2-oct.-2013 à 11:49, Roopesh Chander <[email protected]> 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:
>blockquote
>
> still blockquote
>
>\tblockquote or code block?
>
> \tblockquote or code block?
<http://johnmacfarlane.net/babelmark2/?normalize=1&text=%3Eblockquote%0A%3E%0A%3E+still+blockquote%0A%3E%0A%3E%09blockquote+or+code+block%3F%0A%3E%0A%3E+%09blockquote+or+code+block%3F>
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
[email protected]
http://michelf.ca
_______________________________________________
Markdown-Discuss mailing list
[email protected]
http://six.pairlist.net/mailman/listinfo/markdown-discuss
