30

Do we need to change all tabs into four spaces?

A while back I proposed a code golf specific feature request.

I now come to this community to discuss how this feature may be interesting to many sites throughout the network. In sites that are not technologically oriented tabulation may present a convenient way to format items. However, for a significant portion of technologically-oriented sites (Super User, Stack Overflow, Code Review) whitespace sensitive code is presented. Major languages like python are dependent on the whitespace in the source. Also, C makefiles generally need tabs for proper functioning. Pasting in sources from these environments is common and we should not make it more challenging to do so.

As far as I know, allowing users to type tabs into questions presents no significant challenge or risk to this network's security. Would it be possible to make this change?

Code-golf specific argument

It may make more sense to stop expanding tabs into four spaces. If the browser side code can be made to render tabs as four spaces, this issue is moot. Some submissions especially in languages like Python (and to an even greater extent whitespace) answers as well as some input samples require a literal tab in the source and there should be a way to indicate that.


Pros

  • Support across a wide range of source environments
  • User experience

Cons

  • Mildly inconsistent formatting

Overall, I do feel (and this opinion is backed by the lack of downvotes on the linked meta post) that this network would significantly benefit from this change. Please strongly consider this appeal.


  • Absolutely nothing. Well, I guess I'll just have to have my bounty go to waste... :( – DJMcMayhem Oct 26 '16 at 16:58
  • 3
    @DJMcMayhem rip... I wish there was a way to store the bounty to have it go to the first official answer. I have seen an instance where a temp account was made to store the bounty, but I think it's frowned upon. – Rohan Jhunjhunwala Oct 27 '16 at 21:58
  • 3
    Here's the latest incidence of this issue causing serious problems over at PPCG; the tab-to-space conversion made an answer unusable, destroying information via nonreversibly transforming the post, and even the original answerer was unable to exactly reconstruct what the original answer was. (Luckily, we managed to find an approximate reconstruction that was a slightly better answer to the same question, but the inability to copy-and-paste tabs and Esc charactes still hurts.) – ais523 Jan 7 '17 at 9:12
  • Its shameful to see another bounty go to waste – Rohan Jhunjhunwala Jan 13 '17 at 2:16
12
+100

Today, I found an answer displaying tabs correctly! This is how to do it:

	

Note that this only works if you put the code within a <pre><code> block, which means you also have to escape < with &lt; (and & with &amp; in certain cases), so it's still annoying, but if you do a find/replace on your code, you can make it work.

If you really need to display tabs correctly, this workaround helps.

Example usage:

This markdown:

<pre><code>i=0;j=10  
while i &lt; j:  
&#9;print(i, '&#9;Tab,    4spaces')</code></pre>

is displayed as this:

i=0;j=10
while i < j:
	print(i, '	Tab,    4spaces')

Final note:

I still think that tabs that are not specially escaped should be displayed as tabs, so I'm still hoping that this will get changed in the future.

  • 1
    The first tab (before print), renders as 8 spaces on my chrome browser, not 4. And the second renders as 6 spaces, inconsistent at best, ugly for sure.. – Tensibai Apr 19 '17 at 9:45
  • (As the same width as 8 and 6 spaces, not literal spaces, I wonder how it would look like with longer code. – Tensibai Apr 19 '17 at 9:53
  • 1
    @Tensibai Tabs have varying lengths based on how many characters are ahead of them. What you are seeing is the correct behavior, as the 2nd tab has 10 non-tab chars before it, and 10 % 8 is 2, so 8-2 is 6. The width of a tab is browser-defined. Also, I never claimed a tab was 4 spaces. The string 4spaces is placed after spaces, not a tab. – mbomb007 Apr 19 '17 at 13:58
  • You miss the point, having 8 spaces tab will turn into heel as soon as there's 3 tabs on start of line. That's unpractical and ugly. I'd be curious what the rationale is for 6 char wide tab before 4 'text' chars btw. Displaying tabs as tabs will break display in a bunch of way, if you really want to copy with the tabs, clic edit, remove the code block, copy and cancel your edit. That 's not as straightforward but less error prone than leaving tabs on display IMHO. – Tensibai Apr 19 '17 at 14:07
  • It is not for the code to be run, it is simply for showing that it renders correctly. – mbomb007 Apr 19 '17 at 14:09
  • Let's say we disagree on the ´properly' then :) – Tensibai Apr 19 '17 at 14:14
  • Your argument that it's "ugly" isn't really a valid reason. – mbomb007 Apr 19 '17 at 14:16
  • Tested with just 3 level of indentation on short code: i.stack.imgur.com/AfFHj.png I let you imagine what it could give with longer code on actual answers. – Tensibai Apr 19 '17 at 14:23
  • And then SE should add a notice somewhere telling chrome users to install this add-on ? What about chrome on android ? And other browsers ? That's not what I call something usable and rendering 'properly'. Just my 2 cts. – Tensibai Apr 19 '17 at 14:31
-6

Mildly inconsistent formatting

Declining because you spelled "wildly" with an m for some reason.

We should work on changes to make posting code that doesn't look like crap easier for folks, not the opposite...

  • 2
    Could you please elaborate as to how allowing tabs as an identation choice would change the visual presentation of the information on the page? Wouldn't you be able to render tabs as four spaces on the client side? mbomb's answer demonstrates that tabular indentation works and renders properly in an answer post? Plus, isn't code that has been broken by stack exchange (because it depends on tabs) crap in its own sense? – Rohan Jhunjhunwala Apr 19 '17 at 0:13
  • 2
    You can use tabs as indentation all you want, @Rohan; they're only changed to spaces prior to being rendered. This ensures two things: 1) doesn't look like crap if your browser renders 8-space tabs, 2) doesn't end up polluting someone else's codebase with tabs if they copy-paste. We wouldn't have this problem if folks only used tabs for MAKEFILEs, but... – Shog9 Apr 19 '17 at 0:20
  • That's why people should use "show whitespace" in their text editor of choice. – mbomb007 Apr 19 '17 at 14:02
  • 3
    @Shog9 The recent developer survey shows that more SO users prefer tabs, so your argument isn't really valid. It means that forcing spaces will be more likely to pollute their codebases. – mbomb007 Apr 19 '17 at 14:13
  • 1
    Actually, the survey results indicate that a majority of users prefer some spaces, @mbomb007 - thus tab-purists will need to convert them in a majority of cases anyway. Even when you get lucky and the author used the same indentation settings, we're left with posts that look like crap in some browsers because they assume 8-character tab-stops... We started out this way, and it was terrible. – Shog9 Apr 19 '17 at 15:30
  • 2
    I am all for spaces. I wish tabs would fall off the edge of a cliff. That said, sometimes it is important that the tab is preserved. Especially in programming where a tab is more than just style, a tab versus spaces could mean the difference between a valid question and a non-reproducable one. If the formatting is messed up, that's the fault of the OP, not Stack Exchange. Inconsistent indentation as far as the number of spaces is also ugly, but I think nobody would suggest that Stack Exchange fix that. – zondo Apr 25 '17 at 20:11

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .