Elastic Tabstops — An End to Tabs vs. Spaces?

An anonymous reader writes "Along with Vi versus Emacs, the tabs versus spaces argument must rank as one of the classic holy wars among coders. Here's an attempt to solve it by making tabstops expand or shrink to fit their contents. The concept's pretty cool to use, so be sure to have a play with the demo!"

Comments

Re:A standard tab length would be easier

[Jeremi]

I think this is the wrong kind of solution to the problem. A standard would be easier. Just have someone say "Tabs are now officially SOME_NUMBER spaces long, so fuck you."

You might as well tell the world "Earth's official language is now officially Esperanto, so fuck you". The effect would be about the same.

From Wiki

[neonprimetime]

Use of the term "Holy War" implies that the root of the disagreement is a clash of values, and intractible of resolution except by agreeing to disagree.

My bible says it is morally wrong to use Vi.

Re:From Wiki

[Kesch]

:s/Vi/Emacs/g

Re:From Wiki

[jc42]

My bible says it is morally wrong to use Vi.

Well, of course it is. VI is Latin for 6, which is 1/3 of 666, and we know what that stands for.

As further proof, check vi's origins. It came from Berkeley, and their BSD system has a little d[a]emon as a symbol. Spawn of Satan, QED.

Re:From Wiki

[DesertWolf0132]

Mine says,

"And behold sayeth the Lord, thou shalt edit thine text in Vi and Vi alone, even when thou art forced by the unclean luser to useth the operating system of unholiness. Thou shalt always keep a copy of the Holy editor on thine key of the USB lest thou shalt fall into temptation and edit thine text in the way of the unclean. Any who useth Emacs or the accursed notepad shalt be stricken from the Book of the Holy Sysadmin for all eternity. So sayeth the Lord." -1st Epistle to the Admins of Systems 1:15-16

There it is in black and white. Vi is the way of truth and light. All others are unclean.

Re:From Wiki

[Ed Avis]

Nope, afraid not. vi is a modern-day abomination. Ed is the standard text editor.

Re:From Wiki

[kimvette]

However, in the second book of Coders, 1:2-5, we find the following:

2 And BOFH called a little coder unto him, and set him in the midst of them, 3 And said, Verily I say unto you, Except ye be converted, and become as this emacs user, ye shall not enter into the kingdom of unix. 4 Whosoever therefore shall humble himself as this little coder, the same is greatest in the kingdom of unix. Then were there brought unto him other little coders, that he should put his hands on them, and give them emacs: and the admins rebuked them. 4 But BOFH said, Suffer little coders, and forbid them not, to come run emacs: for of such is the kingdom of unix. 5 And he compiled their emacs, and departed thence.

I call contradiction!

Re:From Wiki

[DesertWolf0132]

Vi came to fulfil the law of Ed as Christ came to fulfil the law of Moses. Come forth into the baptism of the Holy Vi and be saved!

Re:From Wiki

[DesertWolf0132]

You left out verse six:

6. And behold the emacs did vex their souls for the BOFH hateth the coder who is loathe to select and compile an editor unto himself and loveth those who shalt compile for themselves the holy Vi. Yea verily I say unto thee that from that day those coders fell into error such that the BOFH sayeth, "This bringeth joy to my soul as great as the Holy Lager, that these coders might vex themselves with that which is unclean." 7. And the BOFH did laugh much at the pain he hath sent out upon the coders.

How we got here

[Animats]

The way we got into this mess is that in early versions of UNIX, tab stops were set to 8 spaces in the TTY handler. This was not because tab stops were intended as indentation. It was because an ASR-33 teletype could tab that far in one character time. It was for optimizing output time. (Back in those days, TTY output processing had to have time delays to handle the mechanical lag in printers. "How many nulls were required after each carriage return" was an issue, and better systems kept track of the printing column position and adjusted the delay accordingly. Peripherals used to be really dumb.)

If some reasonable indentation value like 4 or 5 had been chosen, everything would have been fine.

Re:How we got here

[Mr Z]

Not just mechanical output devices. I wrote a TTY driver for a Viewpoint terminal that I was driving from an 8052. That thing needed delays all over the place. (Imagine my surprise, years later, to open one up and find an 8051 sitting in there.) I actually discovered it needed delays from the UNIX side of things, because the first thing I implemented was a serial-to-serial pass through, and I had to mess w/ the various stty delay settings before I stopped losing text.

But, yes... 80 columns goes back to Hollerith, and 8-column tabs goes back to an old teletype.... and yet these standards persist. :-) I personally expand all tabs to spaces just to avoid tab damage. I've gotten some horribly dainbramaged files over the years and never like being on the receiving end of that.

--Joe

whether or not this solves the problem

[yagu]

Whether or not this solves the problem (I don't think it does), I get real nervous when source code starts being perceived as a document that lends itself to proportional fonts. Maybe I haven't been in the latest and greatest IDEs lately and am missing something here, but source code seems to scream for canonical form, and proportional font is not that.

I think vim has a reasonable approach (do the research: shiftwidth, tabstops, softtabstop, etc.), I assume there are other approaches in emacs.

Start talking about proportional font source code documents, and now everyone's going to want to have styles, and all the confusing garbage that is word processing. As difficult as source code and programming is, it doesn't need to be more nuanced in word processing.

Re:whether or not this solves the problem

[bogado]

I think that this is good, I aways thought that tabs for identation is simply a better idea just because it made simple for people to see the code the way they feel more conforable with. I don't think 'styles' is a problem, it is just the oposite, imagine if we could make a "style sheet" of some sort and apply to the code and sudenly all the code you load into your editor is styled as you liked?

I use the command line program ident to apply my style to other people's code, sure I don't send them this way I read the code and then just 'undo' before altering the file. But all of this would simply be better if we could style the code without touching it.

Re:whether or not this solves the problem

[mdfst13]

"imagine if we could make a "style sheet" of some sort and apply to the code and sudenly all the code you load into your editor is styled as you liked?"

Yeah, but people would still screw it up.  For example:

  // K&R style -- comments on the if/else go before
if () {
  // comments on the if clause go after the first {
} else {
  // comments on the else go after the else {
}

  // BSD style
if ()
{
}
else
{
}

  # Conway style
if () {
}
  # This also is a problem with BSD, but I thought I'd put it here.
  # Comments on the else clause go between the closing } of the if
  # and the else {.  Net result?  Hanging elses.  I.e. someone removes
  # the if () {} but does not realize that there is an else.  Further,
  # since an if can only be closed by lookahead, this results in real
  # oddities, like the else clause attaching to the previous if.
else {
}

I find the last to be the single ugliest syntax.  The theory behind it is that it is best to put keywords in the left most column.  However, the problem here (IMO) is that an else is irrelevant without the surrounding block structure and the if.  Thus, IMO, it makes sense to write it } else {, as that indicates that the } does not close the if; instead it closes the if true clause before opening the else not true clause.  I actually prefer BSD as being more consistent.

Anyway, the problem that your stylesheet would have is that the syntaxes are fundamentally incompatible.  In BSD and Conway, you can put line comments (//) after the } and before the else.  In K&R, you can't.  Now, you might argue that the stylesheet could move the comment.  However, if you do that, then you lose information.  Why?  Because any other location for the comment in K&R already has an equivalent in BSD/Conway.

What's really needed is a single, canonical way of formatting saved code.  Then developers can apply the stylesheet to the canonical form when viewing.  This canonical way would have to prohibit those practices that only work in some of the representations but not others, e.g. comments in between } and else. 

Re:A standard tab length would be easier

[linvir]

I move that we temporarily adjourn proceedings and reconvene on Thursday of next week, for the dupe.

Re:A standard tab length would be easier

[Jeremi]

I must have missed the part of the discussion where tabs/spacing became intimately interwoven into human culture and society.

They became interwoven into the computer-programming subset of society back in the 60's and 70's, if not earlier.

But even beside that, a lot of things are set semi-arbitrarily in the tech world. So why not the length of a tab?

Because the proposal isn't to define a new standard, it's to re-define a very well-entrenched (if crappy) existing standard. All 60 million people who are already happily accustomed to doing things the old way will simply ignore the new "standard", and a standard which nobody uses is worthless.

Re:A standard tab length would be easier

[Daniel_Staal]

Actually, it is attempts to do that which have created the current confusion. Some were obviously too long, some obviously too short, and the end result is tabs which aren't useful.

I actually like this idea, because it actually you from using this seemingly-simple but in actuality horribly complicated idea that tab = x*space. Instead they have an actually simple idea: Each tab is a seperate column of text. Line up items in the same column with each other. (Of course, how simple this is in practice is yet to be deterimined, but it seems simpler to me.)

This idea is actually about seperateing sementic and content info. Programmers use tabs (those who do) to convey sementic info. If we can make the program understand that, then we can offer more flexiblity to the user on how to present the information.

Re:A standard tab length would be easier

[aymanh]

I want to be able to indent or unindent the opening statement for a given loop, be it int, sub, function, if, for or else, and have the entire section that it describes, including the braces, indent accordingly.

In Vim: Press shift+v to highlight the current line, go to the opening brace, press % to go to the closing brace (highlighting the whole block in turn), then press = to auto-indent.

In command mode, == auto-indents the current line, << and >> indent to right and left respectively.

Back to the original article, I have the following in my .vimrc:

set et
set sw=2
set sts=2
set smarttab

These options replace tabs with 2 spaces when pressing the tab key, indenting, and auto-indenting.

Re:A standard tab length would be easier

[GroeFaZ]

Anyone know of an editor that has this?

If you want that from an IDE, eclipse does that, and pretty robustly at that. I wouldn't want to miss it.

For more simple editors for a quick text edit, my favorite is EditPlus. It lets you choose between classical tabs and whitespace tabs, as how long (in characters) a tab in either mode should be treated, it has the auto-indent you mentioned, reacting to freely definable characters (for example, auto-indent forward after '{' or '(', and back after '}' or ')', respectively). Best of all, it lets you define these parameters independently for plain text, c/c++, java, HTML, Perl, etc., etc., as well as any number of custom syntaxes you may wish to import or define yourself. A small selection of useful features of a great tool. Disclaimer: I am in no way affiliated with Editplus or the company behind it, just a happy user.

Re:A standard tab length would be easier

[kevlarman]

i was about to comment on how key combinations like that are why i use emacs, then i realize...
C-Space C-c } Tab

It's not a comment about Microsoft.

[Ayanami Rei]

So, uh. What the fuck does VS have to do with anything?
I've never used it so I can't comment. So it has variable-width fonts and logical indenting and spacing? Good for them.
If it appears in anything _besides_ Visual Studio I'll be a happy camper.

Re:A standard tab length would be easier

[GroeFaZ]

How can you tell whether nobody will use a new standard if it is significantly better than the old one? If you admit the old standard is crappy, why not even try for the better? Considering how tabs tend to break across platforms or even across applications, it already seems like everyone is doing what he wants anyway. Doing or not doing things because "that's the way it used to be and we don't want change because change is hard" just doesn't make sense, especially considering the fact that we're talking about computers. That's not exactly a field whose methods are carved into proverbial stone like, I don't know, metal smithing, pottery, or something ancient like that.

Re:A standard tab length would be easier

[doshell]

La lingvo oficiala da tero estas Esperanton, tial fiku vin!

Mi pensas, cxu "fikugxi" ne estas pli tawga vorto? :P

Saluton, karaj esperantistoj!

Re:A standard tab length would be easier

[peterpi]

I can't understand why people still find this a problem. It's so simple. Tabs indent, spaces line up. In other words

• space means "move to the right by exactly one character width"
  
• tab means "I want to indent, move across a bit". "A bit", and "across" mean whatever you like. It could be right8 chars, right 4 chars, left 2 chars, down 947565 chars, whatever you like. That's the beauty of it; everybody gets to view it in their favourite format.
  

It's so simple, it's quite embarassing for the whole of the computer-literate society that people still get their kickers in a twist about it.

Anybody who tries to lay down the law by saying that a tab must be 4, 8 or 2 characters' width has missed the point of the tab key completely.

As for your wish, I'm willing to bet money that either vim or emacs will do it for you.

Re:A standard tab length would be easier

[Intron]

So far as I know, "tab" has always meant "Advance the carriage to the next tab stop" and has never meant "advance a fixed number of spaces". The default tab stop setting varies from program to program. In Word its on 1/2" boundaries, and in most editors its on 8-character boundaries.

The subject of tabs vs spaces should be clear

[frn123]

The subject of tabs vs spaces should be clear enough to everyone.

Let me quote the relevant standard:

Linux kernel coding style
[cut]
First off, I'd suggest printing out a copy of the GNU coding standards,
and NOT read it. Burn them, it's a great symbolic gesture.
[cut]
                  Chapter 1: Indentation

Tabs are 8 characters, and thus indentations are also 8 characters.
There are heretic movements that try to make indentations 4 (or even 2!)
characters deep, and that is akin to trying to define the value of PI to
be 3.

Rationale: The whole idea behind indentation is to clearly define where
a block of control starts and ends. Especially when you've been looking
at your screen for 20 straight hours, you'll find it a lot easier to see
how the indentation works if you have large indentations.

Now, some people will claim that having 8-character indentations makes
the code move too far to the right, and makes it hard to read on a
80-character terminal screen. The answer to that is that if you need
more than 3 levels of indentation, you're screwed anyway, and should fix
your program.

In short, 8-char indents make things easier to read, and have the added
benefit of warning you when you're nesting your functions too deep.
Heed that warning.

[cut]
But even if you fail in getting emacs to do sane formatting, not
everything is lost: use "indent".

Now, again, GNU indent has the same brain dead settings that GNU emacs
has, which is why you need to give it a few command line options.
However, that's not too bad, because even the makers of GNU indent
recognize the authority of K&R (the GNU people aren't evil, they are
just severely misguided in this matter), so you just give indent the
options "-kr -i8" (stands for "K&R, 8 character indents").

"indent" has a lot of options, and especially when it comes to comment
re-formatting you may want to take a look at the manual page. But
remember: "indent" is not a fix for bad programming.

Linus Torvalds.

Re:A standard tab length would be easier

[peterpi]

I vote for TAB = however many spaces you want it to be. If you meant "move to the right by the width of four characters", press the space bar four times.

Re:Source code is not a table

[DrMorris]

I do use the tab key as a means of stepping along a number of spaces but the resulting files has exactly the number of space characters that are necessary and no tab characters at all.

Yeah. And this is exactly the way it should be today. In mature Emacs modes for example, pressing the TAB key doesn't necessarily mean that you insert an ASCII TAB character, instead it indents to the right place. Modern editors should take the burden of 'manual' indenting from the coder and instead let him focus on the semantics (without introducing a new 'standard').

Re:A standard tab length would be easier

[peterpi]

You might as well try and define what the 'end' key does. Or better still, define what the F7 key does.

Tab is already standardized. It means either "move onto the next record" in tabular data, or in programming languages "indent". If you have a preference for how much like code to be indented, then you get to set your editor in accordance. Indenting code with tabs is far more considerate than indenting with spaces. Indenting with tabs says "Indent a little. I trust you to set your editor accordingly". Indenting with 4 strikes of the space bar says "In my opinion, four spaces, not two, nor eight, nor six, is the only way to indent. If you want to read my code you shall accept my rules".

Consistency is better than religion

[morrison]

For several large projects I work with where there are lots of developers, consistency of the source code is considerably more important than any particular developer's opinion on what the correct behavior of tabs and spaces are. These are projects where it is pretty much expected that there are or will at least eventually be developers that use both vi and emacs with zealotry as well a myriad of IDE environments. For at least vi and emacs, all source files utilize a local variables block that is understood by both editors in order to encourage a project-defined convention with consistent indentation:

/*
* Local Variables:
* mode: C
* tab-width: 8
* c-basic-offset: 4
* indent-tabs-mode: t
* End:
* ex: shiftwidth=4 tabstop=8
*/

With that comment block at the very end of all source files (whether they be C, C++, Tcl, Perl, Sh, SGML, etc), we do quite well in maintaining order and minimizing the indentation dispute. For the IDE environments, it at least gives them clear documentation on how to configure their IDE indentation preferences to match in every file. Maintaining a tabwidth/tabstop of 8 ensures consistent source display in most environments, including text printing and console display, leaving projects to simply define what offset/shiftwidth level they want for indentation. It can similarly still be tweaked for the projects that seem to insist on no tabs or want to match some IDE default religion.

Re:A standard tab length would be easier

[linvir]

I'm sure a lot of things seem so simple when you're so ignorant of the actual issue.

Why does the PEAR coding standard insist on space-only indentation?
Using spaces and avoiding tabs is the only way to ensure that a piece of code is rendered consistently in all editors and viewers. Many editors render tabs as 4 spaces, and a lot of editors, terminal programs and utilities render tabs as 8 spaces.

Re:A standard tab length would be easier

[jonadab]

> I think this is the wrong kind of solution to the problem. A standard would be easier.

Clearly you are not familiar with the tabs-vs-spaces argument.

Advocates of tabs say that having everything indended by multiples of some standard
amount is a good thing.  This is, of course, wrong for source code in many computer
languages, because it prevents things from being indented to the correct position
relative to the line above, as in the following example (in the Inform language)...

Object matchbox kitchen_cupboard
class cardboard,
  with short_name "matchbox",
       description "A standard cardboard matchbox.
                    It says ~Strike on Box~ on the side.",
       name 'matchbox' 'box',
   has openable container;

I suppose it doesn't matter for write-once applications, but if you're trying
to write _maintainable_ code, it's essential to have things line up properly,
and that means they often need to line up under specific characters on the line
above.  That's possible with tabs if the character they need to line up under is
preceded by whitespace (as it generally is with e.g. SQL), but if that's not so,
tabs are useless.  I don't see how these new "expanding" tabs change that.

Inform is the *best* example I know of a language that *cannot* be properly
indented with only tabs, i.e., spaces are *needed*.  There are other languages
with which this is somewhat true, e.g. Lisp (wherein you often want to line up
under a specific open-parenthesis which may not be preceded by whitespace)
and Perl (although most Perl code is not indented as well as it could be,
partly because tools such as cperl-mode do not support it).

If you agree on a fixed width for tabs (e.g., 8 characters), you could use a
mixture of tabs and spaces, but that won't make tab-indentation advocates happy,
because they want to get *rid* of leading spaces and use tabs only, usually
because they want to use proportional fonts.  If you're going to use spaces
for indentation, you might as well use all spaces and no tabs.

Re:A standard tab length would be easier

[brianmf]

Using spaces and avoiding tabs is the only way to ensure that a piece of code is rendered consistently in all editors and viewers. Many editors render tabs as 4 spaces, and a lot of editors, terminal programs and utilities render tabs as 8 spaces.

Wait. Doesn't this miss the entire purpose of tabs?

I like to see my code indented by the equivalent of two spaces. The other coders in my team like to see their code indented by the equivalent of four spaces. Do we engage in massive edit wars in cvs? Do we regulate a specific number of spaces so that some portion of the team is unhappy? No. I setup my editor to display tabs as the equivalent of two spaces, and the others setup theirs to look like 4 spaces. Everybody is happy.

Regulating a specific number of spaces is sub-optimal. It totally removes a coders flexibility to see the code how they prefer.

Don't mix em.

[Spudley]

I don't mind tabs. I don't mind spaces.

But God help you if you mix them together in the same program.

I've met editors that put four spaces for the first indent, then a tab for the second (removing the previous four spaces in the process). It was fine when you viewed the code in that particular editor, but open the same code in another editor with different tab stops, and it became practically unreadable. If they'd stuck with just tabs or just spaces it would have been fine, but nooooo.... some bright spark had to mix 'em together. Grrrrrrr.

(For what it's worth, the editor in question was LSE, on a VMS system. I don't know to this day whether that was the default setting or a setup made by someone at the company, but it caused a nightmare when we ported the system to Windows)

Re:A standard tab length would be easier

[swansontec]

This is how I code, at least in C-like languages. You can set your tab length to whatever you want, and my sources still look pretty:

int foo ()
{
    //Every line starts with tabs:
    if (
        some_really_long_expression &&
        some_other_really_long_expression
    ) {
        DoSomethingClever(42);
        DoSomethingComplex(
            param1,         //Tabs start the line, spaces between param and comment
            param2,         //Comments line up, thanks to spaces
            param3          //Tab can be any length, whole line moves in or out
        );
        return -1;
    } else {
        return rand();
    }
}

Re:A standard tab length would be easier

[peterpi]

And they make the fundamental misunderstanding in the very first sentence! Why is consistency desireable? Why should my text editor render code consistently with yours? We could be using a different font in a differerent point size at a different resolution. Is that important too? I have white text on a black background on one machine, black on white white for the other. If you specifically need some lines of text to be lined up with each other (consistency within the confines of the document), use space. If you just need it to be shunted over to express intent, use tab. That way we can both set tab to look exactly how we want it to.

eg: (---> means 'tab', '.' means 'space')


void foo ()
{
--->if (something)
--->{
--->--->/* I like to format my comments so that
--->--->.* the stars make a vertical line,
--->--->.* but I don't care how much you like to
--->--->.* indent */
--->--->bool something = SomeLongFunction() &&
--->--->.................Another()
--->}
}

This code satisfies everybody with a good text editor. If you like 8 spaces, set your editor so. If I like 2, 7 or 3.14 I can set mine. Pressing space n times annoys everybody who likes 2n, n/2 or any other number of spaces.

That way they can get on with arguing over important issues like the placement of {

;)

Re:A standard tab length would be easier

[What is a number]

I am also of this camp, in that Tabs are only allowed at the beginning of the line. I do get complaints from others about this part:

1.
              param2, // Comments line up, thanks to spaces

if param2 changes (ie, imagine a more complicated line), you waste time re-aligning the comments. Of course, with tabs=3 or 4, you might also need to realign, just not as often.

The other complaint is similar - aligning #defines:

2.

#define Foo 17
#define BARBARBARBAR 18

people don't like aligning these by spaces - it just isn't as quick. Even I don't like using spaces here, but I do it because I believe in tabs-only-for-indenting as the best overall rule.

I'm tempted to either

A. find (or somehow customize) an editor that will change tabs to spaces ONLY in the middle of a line
or
B. make a hot-key that turns tabs=space on/off, so I can turn it on while doing #defines, then shut it off. So my #defines are aligned with spaces, but I used tabs to enter them.

Any other suggestions? 1. and 2. are the only arguments against tabs-only-for-indenting that I think are somewhat valid, and I'd like to get rid of them.

---
I type this every time.

Uh... ok...

[zizzo]

I read the article and played his demo. I'm not excited by this at all for 2 reasons: it invents yet another model of tab spacing and it encourages use of tabs.

Tabs just need to go away so we can get back to real debates, like CR vs. CR/LF vs. LF.

Re:A standard tab length would be easier

[Breakfast Pants]

Ughhh. If it were so simple everyone could just pipe everything through GNU indent and get everything in the format they want. It isn't so simple.

Re:A standard tab length would be easier

[NoMaster]

A standard would be easier. Just have someone say "Tabs are now officially SOME_NUMBER spaces long, so fuck you."

I thought they had...

[History lesson]

Typewriters - very early typewriters - had tab stops equivalent to 8 spaces. That was it; no ifs, no buts, no negotiation. Later models had the first tab stop equivalent to 8 spaces, then 2 or 3 adjustable tab stops inside that. Even later ones had the first stop adjustable was well.

Y'see, the TAB key is short for "table" - it was designed to make it easy to print tabulated data.

Notice I was very careful to say "equivalent" above - a TAB is not equal to 8 spaces! Nor is it equal to 2, or 4, or 6, or anything else you want to dream up. It's a character in its own right; one whose most common representation is as a gap the same size as 8 spaces.

Somewhere along the line, people involved with computers decided that TAB was actually a macro that meant "print 8 spaces". This was a departure from accepted philosophy and, like most such schisms, led to the Holy War that is still going on. And, like most Holy Wars, people come up with brain-dead attempts at reconciliation that ignore the cause of the problem.

Ever wonder why a config file like /etc/sudoers warns you "This file MUST be edited with the 'visudo' command"? No, it's not to prove you're 'leet enough to be editing it by forcing you memorize vi commands; the biggest reason is that the fields are delimited by actual TAB characters. Not spaces, but TABs. Look at it in a hex editor sometime...

In short: there are 2 whitespace characters in ASCII - the space, being the equivalent of 1 (average) character wide; and the TAB, being nominally 8 characters, but able to be represented (not replaced!) by whatever you want. Don't confuse them.