[ANN] vfmd

[Michel Fortin]

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


> You asked for a practical (i.e. non-hypothetical) example. I gave an

> example that I consider as practical, asking you whether you think this is

> practical or not. You don't seem to have answered that question. (Whether

> the example is practical or impractical? If impractical, which part is?)


By non-hypothetical I meant problems that some people have experienced, not problem that *could* arise in some circumstances but we don't know if they really have happened. My answer is that this problem doesn't arise in the real world otherwise I'd have seen some complains in the last ten years.


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

> 

> Good idea. However, I'm not able to figure out what the doc can be fixed to.


Perhaps a small section about tabs at the start: "Markdown expects tabs to be aligned to four spaces. If your editor puts a tab stop every four space, using tabs to align things properly on screen will give the expected results. Otherwise it's better to not use tabs at all unless your Markdown parser has a setting to set the tab length to match your editor."

Then also avoid mentioning "four spaces or one tab" anywhere. Just say "four spaces" and let people infer the tab part from the little paragraph on tabs above (and from their previous experience).


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

> 

> So the assumption here is that the user is also using 4-column tabs in his

> code editor (in addition to his text editor), right?


Yes.


> Fair enough. That's a valid use case where from the user's point of view,

> something that was handled correctly earlier is going to break with

> changing tab handling. It's use cases like this that I wanted to know about.


The same thing about copy-pasting code can apply to copy-pasting Markdown snippets in and out of Markdown documents. You don't know just by looking at the document whether those whitespaces are tabs or spaces. If you then proceed to add a line to a list item, or an indented paragraph, you don't need to check which kind of whitespace it was to make sure things will not go astray (as long as your editor is using 4-column tabs).


> So you are saying that: The user's text editor probably uses 4-column tabs.

> The browser uses 8-column tabs. Markdown should bridge this so that the

> 4-column tabs remain as 4-column tabs when seen in the browser. To me, this

> doesn't seem to be Markdown's job.


Well, it has been Markdown's job until now.

I'm intrigued, whose's job should it be? The document author? CSS?


>> In fact, you've just admitted that those are all hypothetical problems, so

>> I feel like you're wasting my time here.

> 

> Whoa. When did I admit that?


When you said: "Frankly, I don't know whether it's biting anyone out there."

But maybe we don't have the same definition of hypothetical. To me, a problem that no one has experienced (after 10 years of Markdown in the wild) is a completely hypothetical problem: it might have happened but we have no evidence of it.


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