[ANN] vfmd

Michel Fortin michel.fortin at michelf.ca
Fri Oct 4 12:14:45 EDT 2013

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

> For obvious input, most Markdown implementations agree. For non-obvious

> input, they behave inconsistently.

But pretty much all current implementations treat tabs the same way (converting them to spaces, with 4-space tab stops). There is virtually no inconsistency, implementations agree. Writing a spec should just be a matter of documenting how it works and moving the the next issue. I fail to see what problem is being solved by changing how tabs are interpreted. I have yet to see one complain from a user about how tabs are handled.

I know you've come up with some examples that would be interpreted better. But unless I'm mistaken, those are theoretical examples made up specifically to demonstrate cases in which a new algorithm is an improvement. I think we should be extra-careful about implementing solutions that fix hypothetical problems.

We could debate this a lot longer, but I don't really feel like wasting time on something I don't see as an issue. Please first convince me that this is a problem that needs improvements, that it is actually biting some people out there, and that the current solution(s) are not practical. Then we'll have some data points to discuss possible fixes for those problems.

> I guess anything that exists in the document should be considered as being

> put there intentionally.

Have you never copy-pasted text containing tabs without noticing? It's often hard to notice that tabs are actually tabs and not just a bunch of spaces until edit that line. What you notice more however is whether things properly align or not in your editor.

> As far as I know, most browsers use 8 as tabstop by default, so it's fairly

> consistent.

It's not consistent with Markdown's 4-space tab stops.

Michel Fortin
michel.fortin at michelf.ca

More information about the Markdown-Discuss mailing list