[ANN] vfmd

[Michel Fortin]

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


> Let us consider the example I gave in my last mail, which to me looks like

> a practical use case. Let me elaborate on it here:

> 

> 1. Consider a user who sets his text editor to keep tabs as is (and not

> expand it to spaces)

> 2. This chap wants a code block inside a blockquote in his Markdown

> document

> 3. This is the first time he's tried to write a code block inside a

> blockquote, so he consults the user doc

> 4. The user doc says:

>     (a) "For code blocks, indent each line with 4 spaces or 1 tab"

>     (b) "For blockquoting, start the line with '>' followed by an optional

> space.".

>     (c) The doc gives examples of blockquotes containing code blocks that

> use 4 spaces after the "> " of a blockquote

> 5. After reading the doc, the user naturally writes

> (.=space;_=tab;tabstop=4):

>> .__code block

> (or)

>> ___code block

> 

> Would you consider the above example hypothetical - something that cannot

> happen practically? If yes, which step(s) above would you term as

> impractical?

> 



> That is:

> 1. Is it impractical to assume that a user would set noexpandtab? (Y/N)

> 2. Is it impractical that the user would want to have a code block inside

> a blockquote? (Y/N)

> and so on.


What would be quite surprising is a user who wrote this without checking the HTML result. Especially since visually in the editor it doesn't look like there is enough indentation. If someone wanted it to work that way, I'd probably have received a complain by now. Instead, what happens is that users in this situation "fix" their documents so the Markdown parser would convert it to HTML correctly (adding the necessary spaces).

What should be learned from web browsers and HTML specs is that people don't write against the spec, they write by looking at the result produced by their tools. For Markdown, many don't even look at the produced HTML, they just check that it looks right in their browser.



> Frankly, I don't know whether it's biting anyone out there. But there is an

> inherent value in being self-consistent. The parser should behave in a way

> that is consistent with the user doc. This is violated in the example given

> above.


Fix the doc then! It'll be self-consistent.

It's a much less risky move to fix the user doc to match what the parsers have been doing for 10 years than change the parsers to accommodate the doc (and potentially have everyone go back and "fix" 10 years worth of documents).



> Are you talking about copying code from a code editor (say XCode), where

> we're using tab-indentation in some lines and space-indentation in some

> other lines?


That, and perhaps also stray spaces within tab indentation. It looks right so nobody sees it, and then it gets copy-pasted and Markdown would try to be smart and break everything apart? No thanks.



> In your earlier mail, you had said that "since browsers don't all show tabs

> in a consistent way inside a `<pre>`, it's much better if they get

> converted to spaces". My response was browsers among themselves are

> consistent.


Actually, I think browsers were not always that consistent with regard to tabs. But if they are now, then that's good. I guess I'm not up to date with that.



> I agree that browsers use 8 column tabs and many Markdown implementations

> use 4 column tabs to convert to spaces. But if we leave tabs intact in the

> HTML output, then Markdown and the browsers will be consistent, so all will

> be well? Maybe explaining using an example use case would help here (maybe

> we are copying from XCode and pasting it into our doc, or maybe we are

> copying code from a browser)?


But most users don't want to know about the HTML output! People care about what they see in their browsers, and if the browser converts their 4-space indents to 8-space indents they'll complain. Even more so if it worked correctly before and they're now upgrading to a newer parser that changes the behaviour and "break" old documents.



> As I said earlier, I hadn't understood what you'd meant when you said "I

> didn't think tabs inside code blocks were into question here, are they?".

> Please explain (if you think it's worth discussing, that is).

> 

> Also, I had requested that you provide a few examples of inputs that would

> break if we change handling of tabs. If you have such examples, please

> provide them.


Probably a good portions the pages on my website. I could dig them out if necessary, but right now I don't see the necessity. I have yet to see why your changes are needed. In fact, you've just admitted that those are all hypothetical problems, so I feel like you're wasting my time here.


-- 
Michel Fortin
michel.fortin at michelf.ca
http://michelf.ca