<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Sat, Oct 5, 2013 at 4:38 PM, Michel Fortin <span dir="ltr">&lt;<a href="mailto:michel.fortin@michelf.ca" target="_blank">michel.fortin@michelf.ca</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Le 5-oct.-2013 à 2:45, Roopesh Chander &lt;<a href="mailto:roop@forwardbias.in">roop@forwardbias.in</a>&gt; a écrit :<br>


<div><div class="h5"><br>
&gt; Let us consider the example I gave in my last mail, which to me looks like<br>
&gt; a practical use case. Let me elaborate on it here:<br>
&gt;<br>
&gt; 1. Consider a user who sets his text editor to keep tabs as is (and not<br>
&gt; expand it to spaces)<br>
&gt; 2. This chap wants a code block inside a blockquote in his Markdown<br>
&gt; document<br>
&gt; 3. This is the first time he&#39;s tried to write a code block inside a<br>
&gt; blockquote, so he consults the user doc<br>
&gt; 4. The user doc says:<br>
&gt;     (a) &quot;For code blocks, indent each line with 4 spaces or 1 tab&quot;<br>
&gt;     (b) &quot;For blockquoting, start the line with &#39;&gt;&#39; followed by an optional<br>
&gt; space.&quot;.<br>
&gt;     (c) The doc gives examples of blockquotes containing code blocks that<br>
&gt; use 4 spaces after the &quot;&gt; &quot; of a blockquote<br>
&gt; 5. After reading the doc, the user naturally writes<br>
&gt; (.=space;_=tab;tabstop=4):<br>
&gt;&gt; .__code block<br>
&gt; (or)<br>
&gt;&gt; ___code block<br>
&gt;<br>
&gt; Would you consider the above example hypothetical - something that cannot<br>
&gt; happen practically? If yes, which step(s) above would you term as<br>
&gt; impractical?<br>
&gt;<br>
<br>
&gt; That is:<br>
&gt; 1. Is it impractical to assume that a user would set noexpandtab? (Y/N)<br>
&gt; 2. Is it impractical that the user would want to have a code block inside<br>
&gt; a blockquote? (Y/N)<br>
&gt; and so on.<br>
<br>
</div></div>What would be quite surprising is a user who wrote this without checking the HTML result. Especially since visually in the editor it doesn&#39;t look like there is enough indentation. If someone wanted it to work that way, I&#39;d probably have received a complain by now. Instead, what happens is that users in this situation &quot;fix&quot; their documents so the Markdown parser would convert it to HTML correctly (adding the necessary spaces).<br>


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

</blockquote><div><br></div><div>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&#39;t seem to have answered that question. (Whether the example is practical or impractical? If impractical, which part is?)</div>

<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">
&gt; Frankly, I don&#39;t know whether it&#39;s biting anyone out there. But there is an<br>
&gt; inherent value in being self-consistent. The parser should behave in a way<br>
&gt; that is consistent with the user doc. This is violated in the example given<br>
&gt; above.<br>
<br>
</div>Fix the doc then! It&#39;ll be self-consistent.<br>
<br>
It&#39;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 &quot;fix&quot; 10 years worth of documents).<br>

</blockquote><div><br></div><div>Good idea. However, I&#39;m not able to figure out what the doc can be fixed to. Also, I didn&#39;t get an answer when I asked the same question yesterday:</div><div>&gt; &gt; <span style="font-family:arial,sans-serif;font-size:13px">If you say we should preprocess tabs to spaces before parsing, can you come up</span></div>

<div><span style="font-family:arial,sans-serif;font-size:13px">&gt; &gt; with the right wording for the user documentation that would be compatible with </span></div><div><span style="font-family:arial,sans-serif;font-size:13px">&gt; &gt; the preprocess-tabs method of parsing?</span></div>

<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im"><br>
&gt; Are you talking about copying code from a code editor (say XCode), where<br>
&gt; we&#39;re using tab-indentation in some lines and space-indentation in some<br>
&gt; other lines?<br>
<br>
</div>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.<br>
<div class="im"><br></div></blockquote><div><br></div><div>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?</div><div><br></div><div>Fair enough. That&#39;s a valid use case where from the user&#39;s point of view, something that was handled correctly earlier is going to break with changing tab handling. It&#39;s use cases like this that I wanted to know about.</div>

<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">
&gt; I agree that browsers use 8 column tabs and many Markdown implementations<br>
&gt; use 4 column tabs to convert to spaces. But if we leave tabs intact in the<br>
&gt; HTML output, then Markdown and the browsers will be consistent, so all will<br>
&gt; be well? Maybe explaining using an example use case would help here (maybe<br>
&gt; we are copying from XCode and pasting it into our doc, or maybe we are<br>
&gt; copying code from a browser)?<br>
<br>
</div>But most users don&#39;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&#39;ll complain. Even more so if it worked correctly before and they&#39;re now upgrading to a newer parser that changes the behaviour and &quot;break&quot; old documents.<br>

</blockquote><div><br></div><div><br></div><div>So you are saying that: The user&#39;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&#39;t seem to be Markdown&#39;s job.</div>

<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">
&gt; As I said earlier, I hadn&#39;t understood what you&#39;d meant when you said &quot;I<br>
&gt; didn&#39;t think tabs inside code blocks were into question here, are they?&quot;.<br>
&gt; Please explain (if you think it&#39;s worth discussing, that is).<br>
&gt;<br>
&gt; Also, I had requested that you provide a few examples of inputs that would<br>
&gt; break if we change handling of tabs. If you have such examples, please<br>
&gt; provide them.<br>
<br>
</div>Probably a good portions the pages on my website. I could dig them out if necessary, but right now I don&#39;t see the necessity. I have yet to see why your changes are needed.</blockquote><div><br></div><div>Let me summarize this mail train to help you see the necessity:</div>

<div><br></div><div>1. I proposed an idea to process tabs during parsing instead of preprocessing them</div><div>2. You said: &quot;<span style="font-family:arial,sans-serif;font-size:13px">I think it&#39;s a good idea, but I&#39;m not convinced it is worth the trouble.&quot;</span></div>

<div><span style="font-family:arial,sans-serif;font-size:13px">3. I said, yes it&#39;s a good idea, but it&#39;s not much trouble (&quot;</span><span style="font-family:arial,sans-serif;font-size:13px">Handling tabs everywhere is easy&quot;)</span><span style="font-family:arial,sans-serif;font-size:13px"> </span></div>

<div><span style="font-family:arial,sans-serif;font-size:13px">4. You gave two main reasons why it is trouble: </span><span style="font-family:arial,sans-serif;font-size:13px">(a) implementation work and </span><span style="font-family:arial,sans-serif;font-size:13px">(b) the potential to break current documents</span></div>

<div><span style="font-family:arial,sans-serif;font-size:13px">5. I said (a) implementation work cannot be avoided anyway and (b) show me some examples where current documents will break</span></div><div><br></div><div><span style="font-family:arial,sans-serif">If a &quot;good idea&quot; is rejected because it&#39;s not &quot;worth the trouble&quot;, the discussion should focus on what the &quot;trouble&quot; is.</span><br>

</div><div><span style="font-family:arial,sans-serif"><br></span></div><div><font face="arial, sans-serif">The necessity of providing example inputs is to back your claim that </font><span style="font-family:arial,sans-serif;font-size:13px">current documents will break, and therefore that </span><span style="font-family:arial,sans-serif">changing tab handing will be troublesome.</span></div>

<div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> In fact, you&#39;ve just admitted that those are all hypothetical problems, so I feel like you&#39;re wasting my time here.<br>


<div class=""><div class="h5"><br></div></div></blockquote><div><br></div><div>Whoa. When did I admit that?</div><div><br></div><div>Ok, I have to admit that&#39;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.</div>

<div><br></div><div>roop.</div></div></div></div>