[ANN] vfmd

[Roopesh Chander]

On Sat, Oct 5, 2013 at 4:38 PM, Michel Fortin <michel.fortin at michelf.ca>wrote:


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

>


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



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

>


Good idea. However, I'm not able to figure out what the doc can be fixed
to. Also, I didn't get an answer when I asked the same question yesterday:

> > If you say we should preprocess tabs to spaces before parsing, can you

come up

> > with the right wording for the user documentation that would be

compatible with

> > the preprocess-tabs method of parsing?




>

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

>

>

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?

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.


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

>



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.


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



Let me summarize this mail train to help you see the necessity:

1. I proposed an idea to process tabs during parsing instead of
preprocessing them
2. You said: "I think it's a good idea, but I'm not convinced it is worth
the trouble."
3. I said, yes it's a good idea, but it's not much trouble ("Handling tabs
everywhere is easy")
4. You gave two main reasons why it is trouble: (a) implementation work and (b)
the potential to break current documents
5. I said (a) implementation work cannot be avoided anyway and (b) show me
some examples where current documents will break

If a "good idea" is rejected because it's not "worth the trouble", the
discussion should focus on what the "trouble" is.

The necessity of providing example inputs is to back your claim that current
documents will break, and therefore that changing tab handing will be
troublesome.



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

Ok, I have to admit that's a little weird. Let me just stop discussing this
with you then. Sorry to have wasted your time so far, and thanks so much
for your time and interest.

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