<div dir="ltr">&gt; Anything that is more complex has ripple effects through the test suite<br>&gt; (which has more code paths to check)<br><br>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&#39;t think that can be considered a reason for not making parsers behave more correctly.<br>

<br>&gt; and to the edge cases we need to think about when factoring the spec.<br><br>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&#39;s see if the updated spec has any problems or unconsidered cases.<br>

<br>&gt; One you probably didn&#39;t think of:<br>&gt; &lt;<a href="http://johnmacfarlane.net/babelmark2/?normalize=1&amp;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">http://johnmacfarlane.net/babelmark2/?normalize=1&amp;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</a>&gt;<br>

<br>Methinks, from a user&#39;s point of view, both the &quot;blockquote or code block&quot; 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).<br>

<br>&gt; The more the spec deviates from what the parsers are actually doing, the more<br>&gt; difficult it&#39;ll be to adopt for implementers for two reasons: implementation work<br>&gt; and the potential to break our user&#39;s documents.<br>

<br>Let&#39;s consider each of your reasons one by one.<br><br>### Reason 1: Implementation work<br><br>vfmd can entice developers to adopt it on two orthogonal, sometimes conflicting factors:<br>  (a) It&#39;s easy to adopt it<br>

  (b) It gives the best possible interpretation for any input<br><br>vfmd anyway has a different parsing architecture from most current implementations (per my knowledge), so (a) wouldn&#39;t stand. Just satisfying (a) wouldn&#39;t be very persuasive either. If it wants a chance at being implemented, it&#39;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.<br>

<br>### Reason 2: Breaking existing documents<br><br><div>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.</div>

<div><div><br></div></div><div><font face="arial, sans-serif">roop.</font></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Oct 2, 2013 at 10:30 PM, Michel Fortin <span dir="ltr">&lt;<a href="mailto:michel.fortin@michelf.ca" target="_blank">michel.fortin@michelf.ca</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Le 2-oct.-2013 à 11:49, Roopesh Chander &lt;<a href="mailto:roop@forwardbias.in">roop@forwardbias.in</a>&gt; a écrit :<br>


<div class="im"><br>
&gt; Unless the complexity increases by several orders of magnitude, I would<br>
&gt; think that it&#39;s better to have a parser that gives a more correct<br>
&gt; interpretation, even if it&#39;s at the expense of a little higher complexity<br>
&gt; of programming.<br>
<br>
</div>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&#39;t think of:<br>


<br>
        &gt;blockquote<br>
        &gt;<br>
        &gt; still blockquote<br>
        &gt;<br>
        &gt;\tblockquote or code block?<br>
        &gt;<br>
        &gt; \tblockquote or code block?<br>
<br>
&lt;<a href="http://johnmacfarlane.net/babelmark2/?normalize=1&amp;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" target="_blank">http://johnmacfarlane.net/babelmark2/?normalize=1&amp;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</a>&gt;<br>


<br>
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=&quot;1&quot;, 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&#39;ll be to adopt for implementers for two reasons: implementation work and the potential to break our user&#39;s documents.<br>


<br>
Another thing to factor in:<br>
<br>
- how many documents this new behaviour will break? (hard to know)<br>
- how many people will benefit from the new rules? (is there any?)<br>
<br>
If no one is inconvenienced by the current behaviour then I don&#39;t think it is reasonable burden implementers to change it, even for a theoretically better one.<br>
<br>
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&#39;ve never heard of someone using the option.<br>


<br>
[^1]: See the [parser configuration variables](&lt;<a href="http://michelf.ca/projects/php-markdown/configuration/#markdown" target="_blank">http://michelf.ca/projects/php-markdown/configuration/#markdown</a>&gt;)<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
Michel Fortin<br>
<a href="mailto:michel.fortin@michelf.ca">michel.fortin@michelf.ca</a><br>
<a href="http://michelf.ca" target="_blank">http://michelf.ca</a><br>
<br>
_______________________________________________<br>
Markdown-Discuss mailing list<br>
<a href="mailto:Markdown-Discuss@six.pairlist.net">Markdown-Discuss@six.pairlist.net</a><br>
<a href="http://six.pairlist.net/mailman/listinfo/markdown-discuss" target="_blank">http://six.pairlist.net/mailman/listinfo/markdown-discuss</a><br>
</div></div></blockquote></div><br></div>