[ANN] vfmd

[Roopesh Chander]

> Anything that is more complex has ripple effects through the test suite

> (which has more code paths to check)


I totally agree that tests need to be added (I think that would hold true
even without this new tab-habdling thingie). Any change in behaviour might
involve an update to the tests. I don't think that can be considered a
reason for not making parsers behave more correctly.


> and to the edge cases we need to think about when factoring the spec.


Let me try updating the vfmd spec for handling tabs during parsing (i.e.
without handling them in preprocessing) in a separate branch/fork in
GitHub. Then let's see if the updated spec has any problems or unconsidered
cases.


> One you probably didn't think of:

> <

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

>


Methinks, from a user's point of view, both the "blockquote or code block"
blocks would seem like code-blocks, so I would say that should be the
correct interpretation. (I realize that many implementations interpret it
differently, but we should be more concerned with how it *should* be
interpreted, rather than how it *is* being interpreted by implementations
now).


> 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.


Let's consider each of your reasons one by one.

### Reason 1: Implementation work

vfmd can entice developers to adopt it on two orthogonal, sometimes
conflicting factors:
  (a) It's easy to adopt it
  (b) It gives the best possible interpretation for any input

vfmd anyway has a different parsing architecture from most current
implementations (per my knowledge), so (a) wouldn't stand. Just satisfying
(a) wouldn't be very persuasive either. If it wants a chance at being
implemented, it's got to aim for (b), even if that can be a little
detrimental to (a). It should be easy to adopt, but not at the cost of
correctness.

### Reason 2: Breaking existing documents

Are you talking about list handling or for other parts of the syntax? For
lists, for users using tabstop=4, the behaviour is the same, as we saw
earlier. For tabs within code blocks, the behaviour would be different, but
I would be surprised if users *relied* on tabs within code blocks turning
into spaces in the output.

roop.


On Wed, Oct 2, 2013 at 10:30 PM, Michel Fortin <michel.fortin at michelf.ca>wrote:


> 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:

>

>         >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

> michel.fortin at michelf.ca

> http://michelf.ca

>

> _______________________________________________

> Markdown-Discuss mailing list

> Markdown-Discuss at six.pairlist.net

> http://six.pairlist.net/mailman/listinfo/markdown-discuss

>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://six.pairlist.net/pipermail/markdown-discuss/attachments/20131003/5b3c91e7/attachment.html>