[ANN] vfmd

[Roopesh Chander]

On Fri, Oct 4, 2013 at 9:44 PM, Michel Fortin <michel.fortin at michelf.ca>wrote:


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



No, not all of them. Most of them, yes. As we saw earlier, Kramdown and
Maruku keep them as is. (Which is why you probably added "pretty much"
before "all current implementations".)



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

>


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.

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.

>


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.



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



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?



>



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

>


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.

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

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.

roop.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://six.pairlist.net/pipermail/markdown-discuss/attachments/20131005/09068c15/attachment.htm>