Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Look here: a typical holy war on tabs vs spaces.

Now look here: elastic tabstops. All problems solved, and a bunch of very useful new behaviours added.

elastic tabstops

Are elastic tabstops even mentioned in that tabs vs spaces discussion? Why not? Are there drawbacks to the elastic tabstop idea so serious that nobody has ever implemented them in a popular editor?

EDIT: I apologise for putting too much emphasis on "why aren't they mentioned". That wasn't really what I intended; that question is possibly even off topic. What I really mean is, what are the biggest drawbacks of this that prevent wider adoption of an obviously beneficial idea? (in an ideal world where everything supports it already)

(Turns out there's already a request on the Microsoft Connect for a Visual Studio implementation of elastic tabstops, and a request in Eclipse too. Plus there's a question asking about other editors that implement elastic tabstops)

share|improve this question
23  
+1 for the animated gif! –  gbjbaanb Feb 28 '12 at 10:59
2  
This would be a great question for ux.stackexchange.com –  JonnyBoats Feb 28 '12 at 11:43
9  
They're never mentioned in the "tabs versus spaces" discussion because there is almost no way for a working programmer to use these things. Maybe if you had an Eclipse, VS, gvim and emacs implementation, that might change. –  Paul Tomblin Feb 28 '12 at 12:24
2  
I really like the idea, but it's only when you live with it for a month or so that you really know what the pitfalls are. Like everything ever, there are guaranteed to be some cases where it does things you wouldn't expect... –  Chris Burt-Brown Feb 28 '12 at 15:09
3  
I want this in notepad++...I want this now –  Ben Brocka Feb 28 '12 at 18:03

11 Answers 11

up vote 18 down vote accepted

Holy Wars are Subjective

Nick's elastic tabstops are an amazing concept that could help a lot of people agree on a workable solution, though I highly doubt it would entirely end this Holy War: it is, after all, also a matter of taste and many programmers will not move an inch from their position on this matter, even at the cost of compromise. So that would be a first reason.

For instance, a lot of people on the "spaces" side will still dislike it as it requires an additional piece of logic in your software for a decent rendering (e.g. simply viewing a changeset in your SCM's webview).

Implementation Issues

But the most obvious reason is just its technical barrier to entry: it's a fundamentally different concept from what has been implemented for a number of years (if not decades) in IDEs and text editors. It would require to rewrite some of them to process lines in a fairly different fasion, which makes it difficult for older and bigger systems that have a higher chance of suffering of deep and tight coupling in their line processing code. It is, however, a lot easier to do when you start from scratch (think of Nick's demo or of Go's tabwriter package).

For a personal anecdote, I remember approaching the author a while back to ask if there was any emacs support in sight, and in this particular case he mentioned this as the reason for it not being trivial. He also asked for help from the community to help implement this feature and bring it to the masses.

Do We Care Enough?

A third reason, is that some developers are not that hung up on the matter and don't really care so much that they would go the extra mile to support the effort. In most cases, the spaces-vs-tabs conflict is not a business blocker, so there's not so much drive behind the issue.

If you want it, you'll have to fight for it. Which is doable in open-source software. And if you change enough of these, closed-source ones will have to follow at the risk of losing to some of their userbase, if an ever so small part of it.

So, if you want it, give Nick a hand.

share|improve this answer
    
(off topic) I often wonder how other "this is nice but very minor" kind of features ever make it into products like Visual Studio. It seems that someone on the team just simply found the time to implement it for personal reasons. Think of typing into several lines at a time in Visual Studio, for example; it's not like tens of thousands of people asked for it, but I do rather like it. –  romkyns Feb 28 '12 at 16:47
2  
@romkyns: As for many things, it takes either one quiet insider or a thousand voices screaming at the gates. –  haylem Feb 28 '12 at 17:05
    
If downvoting, please explain why. Thank you. –  haylem Mar 1 '12 at 20:26

They're not mentioned because they're not implemented in most IDEs of text editors; they're a novelty of little real use in a project.

Spaces have been used to lay out programming since the days of punch cards. Tabs came along and someone obviously thought they were a good idea (they were mistaken :p).

In the days where most modern editors can convert tabs to spaces automatically... they are fairly pointless.

Having to install yet another tool to deal with something as trivial as tabs vs spaces certainly doesn't appeal to me, and I don't think it would to most of my colleagues.

share|improve this answer
    
I've cleared the comments as they were descending into insult. –  ChrisF Feb 29 '12 at 16:49
1  
Just thought I'd point out, the main reason why I like the idea of elastic tabstops isn't because it solves the problem of tabs vs spaces, but because of the behavior shown in the GIF in the original question; automatic, pain-free alignment. Plus, for VCS diffs there's the added benefit that there were no whitespace changes required in that example. –  Ajedi32 Feb 7 at 17:25

This is the first time I heard of those. Not sure if they are a good idea but they seem of little use since we have tools (such as indent) that automatically format code already.

What happens when I open your clever elastic tabstops in vim and edit it? Do the tab automatically clean up or are you left with a mess?

The main drawbacks, as I see them are possibly breaking diffs, version control, and not being compatible with editors that do not support them. It maybe a lot of code modification to support them and there are more important things than "yet another tab thing to format code" feature. After all, we can all use indent which does all the above if memory serves.

share|improve this answer
4  
What a backward-thinking attitude. Let’s have no progress because people’s favourite old, outdated tools can’t cope just yet! (The irony, of course, being that these tools (such as vim) are open-source, so if it were really important to you, you could (and probably should) add elastic tabstop support to it) –  Timwi Feb 28 '12 at 12:12
13  
@Timwi: You are utterly missing the point I was making. What happens when your code file is parsed by something that is not aware of elastic tabstops? Do you end up with a mess or can they cope? What about version control and diffs? Just wishing that all tools did support $feature is unrealistic even if those tools are open source. –  Sardathrion Feb 28 '12 at 12:31
14  
@Timwi: You assume that everyone finds elastic tabstops to be as awesome as you think they are. This may not be true. –  Sardathrion Feb 28 '12 at 13:03
7  
@Sardathrion is right. What happens when I have to remote into my *nix server with no windowing system in place and need to examine some code with Vim/Emacs/Pico/Whatever? If there is a mechanism so that it is readable that would be fine...otherwise it would be a nightmare. I don't see the benefit of elastic tab stops being that beneficial anyway. I can already autoformat my code to look how it should in the IDEs I use. –  Rig Feb 28 '12 at 13:16
6  
The version control point is a good one -- I don't think people are going to appreciate an editor that silently starts changing the placement/format of comments in code arbitrarily far away from the code they are modifying (see magenta section in OP's animated gif). It would helpful to have a reference implementation to play with, but what I see so far is not remarkable - emacs already does much of this, just with a couple extra keystrokes (which arguably is a good thing). –  mcmcc Feb 28 '12 at 15:10

I think they'd find much use if IDEs supported them (Microsoft!). Once people found they could slap their flowerboxes at the side and have them nicely readable, they will. You might more comments being added to source code suddenly (which can only be a good thing).

I suppose we could also add comment "tooltips" to the list of 'would it be good if...', so your large comment blocks could be hidden away and viewed easily when needed. Maybe we could also have comment blocks that form part of documentation (not sandcastle type stuff, proper user-readable documentation snippets that were embedded in the code, not just the method headers)

Disadvantages: it might make your source diffs look bad if a bunch of lines looked like they were changed when really only 1 was modified (if the editor saved the file with the tabs converted to spaces). Or, if the elastic tab was implemented with a single character (or more likely, 2 tabstops) then viewing your source outside the editor could look bad.

I think I like the idea though, 'tab tab' at the end of a line elasticates the comment block and lines up all comments on subsequent lines (that have the double-tab spacing) accordingly.

share|improve this answer

Many times I have had to fight with a word processor to get the document to look the way I want without some hidden automatic rule controlling the placement of my words. I don't want to spend one second trying to figure out why the editor is insisting on placing those words there.

share|improve this answer
4  
Nor do I. I fully sympathise with this sentiment, as such rules really frustrate me too. But this is different in two ways. One: Just like tabstops now, you don’t have to use them if you don’t want to. You can leave your colleagues’ text alone if it uses them. Two: Elastic tabstops don’t have hidden rules, but blatantly obvious ones. The behaviour is completely natural — perhaps even more natural than traditional tabstops, which occur at some arbitrary, usually irrelevant, position within the text. This is why nobody uses tabstops for anything other than indentation anymore. –  Timwi Feb 28 '12 at 14:58
8  
@Timwi:The question was to list drawbacks. I did. –  mhoran_psprep Feb 28 '12 at 15:04
9  
It might not be obvious from the GIF, but the only figuring out involved is that when you press "TAB", whatever comes after will come out properly vertically aligned. It's nothing like a word processor. Just try the actual interactive demo at the link I posted, and you'll see how natural it is. –  romkyns Feb 28 '12 at 15:11
3  
@mhoran_psprep: Fair enough, I appreciate your input. I guess we were looking at different interpretations of the question. You are listing drawbacks of yourself using the feature, while I thought it was about drawbacks of introducing the feature (i.e. making it available and not mandatory). –  Timwi Feb 28 '12 at 15:33

The biggest problem I would have with it is inconsistent spacing throughout the documentation. I know as a programmer I would get annoyed to see a loop or if statement at 'standard' indentation and then to notice at different indentations. I know personally I like seeing all my curly braces alined throughout the documentation, not just in the block of code I am looking at.

Overall I think it is a nice idea however, but personally, I would not like it.

share|improve this answer

Here's how I see it: if most of the popular tools already supported elastic tabstops, many people would be using them. The same happened with vi’s navigate/edit mode, with syntax highlighting, and later with Intellisense. In each case, the established wisdom was that it is not useful or not needed, but it got implemented and it took off.

Elastic tabstops do, of course, have a relatively low impact. Most people are sufficiently happy with the status quo and so don’t care. A similar reasoning is applied to many situations in which some people are just happy with what they’ve got and see no reason to switch to something more advanced. In other words, the biggest problem with elastic tabstops is the same as for almost every other good idea: it needs to gain traction.

But that doesn’t mean the feature can’t be adopted incrementally. Every single programming language was adopted incrementally, even though an entire team requires a new compiler and a new IDE to start using it. The same is true of every single hardware architecture and many other examples. It is also not the case that lack of integration with existing tools is a show-stopper: the same is true, for example, of “unified-diff format”, which incrementally replaced an earlier less readable format that was nonetheless understood by automated tools (such as patch). Those tools have been upgraded over time.

I appreciate the interop issues others have mentioned, but despite them, there certainly will be teams (like mine) who would adopt this without hesitation, in our entirety. External tools such as diffing, merging etc. will initially not support it, but we would do our part to encourage vendors to include the feature. This is how progress has always been made. It requires some pains for a temporary transitionary period, but in the end, it is worth it.

share|improve this answer
    
The C vs C++ argument appears a bit misguided. While it may be true taht this is the case for "some people" (as you rightly said), there are obvious reasons to stick to C or favor C++ depending on the situation. The size of the C++ runtime being one of them, in a default setting. –  haylem Feb 28 '12 at 17:10
    
I'm with haylem. Your point would be more sound without the C-versus-C++ comparison. They are quite different languages. To my mind, C is for systems programming and other low-level work where you need a lot of control (a VM, for instance). C++ is more for mid-level applications where abstraction is useful to manage complexity (namespaces, STL containers and algorithms, templates), but performance is still a concern (games being the most visible example). –  Jon Purdy Feb 28 '12 at 18:20
    
@haylem: Thanks for the feedback. I’ve removed the reference to C/C++. –  Timwi Feb 28 '12 at 21:02
    
@JonPurdy: Thanks for the feedback. I’ve removed the reference to C/C++. –  Timwi Feb 28 '12 at 21:02

To be honest, I don’t find them that useful once you get over the initial excitement. For instance, I don’t like comments at the end of a line anyway – I always put my comments on a separate line. With that, elastic tabs lose their main use.

After that, you can of course still use them to align function arguments (and parameters) and long lists of assignments.

But for the former I tend to just indent all arguments by one additional level and that works entirely fine with me:

void foo(
    int x,
    int y,
    string z
)

And I don’t see any need to change that.

And as for aligning assignments, I don’t do that. I put single spaces around assignments, that’s it. I also tend not to cluster lots of assignments together so there is rarely any readability issue.

In summary, elastic tabs have absolutely zero usefulness for me. This is of course a very personal preference that may vary but I find that it works well and I guess that the lack of support for elastic tabs is because other people think similarly.

If an editor would implement them, I still wouldn’t use them.

share|improve this answer
    
Appreciated. It seems that you could happily use a variable width font too if you just wanted to, since you don't align anything other than the start of the line anyway. Visual Studio has pretty good support for this, actually, and the readability boost is nice. –  romkyns Feb 28 '12 at 16:15
    
@romkyns We had discussions about that and in the course of one I tried using a proportional font for programming for some time. The upshot was that monospaced fonts work better, even when disregarding the indentation. Apart from that I’m currently working exclusively in Vim and the console, neither of which will in all probability ever support proportional fonts. –  Konrad Rudolph Feb 28 '12 at 16:22
    
@romkyns That said, these problems are solvable (or perhaps even solved, with a proportional font designed for programming). But I still don’t really see the necessity. –  Konrad Rudolph Feb 28 '12 at 16:25

Emacs already handles indentation in the presence of unclosed parentheses, and will automatically align wilma with fred. I have no idea why Eclipse doesn't do the same. Ok, I have an idea, but it's uncomplimentary.

You could get Emacs to align the comment too, without much trouble, but AFAIK no one but you has ever wanted that.

share|improve this answer
1  
I can only interpret your last sentence as trolling, since obviously at least one other guy wanted it pretty darn badly enough to create a well-argumented page, a Java implementation and a GIF to show why it's good. If you read through the answers, you'll find that Nick isn't alone, either. Oh wait, look here too. –  romkyns Feb 28 '12 at 18:31
    
By the way, does Emacs re-indent wilma as you make edits, such as changing the length of the function name? If it does, that's fairly close to what elastic tabstops do. –  romkyns Feb 28 '12 at 18:43
    
@romkyns: I didn't mean to be trolling, I just meant that I had never seen that style of comment indenting in EMACS. Generally EMACS does not re-indent multiple lines as you type, but that could be changed too. –  kevin cline Feb 28 '12 at 22:08

One drawback is that it doesn't work if you want alignment on one group of lines and then indentation on the next, since it groups the tab stops of adjacent lines.

def foo( bar,
         xyzzy ):
         wibble() # Too much indentation

What I wanted:

def foo( bar,
         xyzzy ):
    wibble()

For curly-brace languages this might be less of a problem, as you can usually solve this by putting the opening brace on a line of its own (like in the animation), but for whitespace-sensitive languages, this quickly becomes a pain, and you end up having to fall back to using spaces.

share|improve this answer
    
Agreed. Nick's implementation doesn't work for languages like Python very well at all. –  romkyns Feb 28 '12 at 20:08
2  
Why wouldn’t this work? This isn’t a fundamental limitation, the algorithm just needs to be language-aware. But to some extent this is true even today, Vim for instance defines different indentation rules depending on the language. This could easily accommodate Python indentation. –  Konrad Rudolph Feb 28 '12 at 20:17
1  
@KonradRudolph No, they couldn't. The draw of elastic tabstops is the ability to automatically indent/unindent groups of text together. One simply example is the end of an "if" statement: You try and un-indent because you're exiting the statement, but the "smart" elastic tabstops decide you meant to also un-indent the line or two above, so on and so forth... And if you have to explicitly group text together, then - what is the point? It's more work to do that than fix the indents yourself... –  Izkata Feb 29 '12 at 3:25
1  
@Izkata Unindenting manually would (should) simply end the current group. Why would you ever control indentation with the elastic tab stops manually? You wouldn’t, so the algorithm knows that when you do it, it’s to end a block, not to un-indent the above block. –  Konrad Rudolph Feb 29 '12 at 8:07
    
@KonradRudolph If you were changing the indenting on something, you would. See the animated GIF in the question. –  Izkata Feb 29 '12 at 15:36

Why don't we just make the vertical tab character (VT, ASCII 11) serve to indicate the use of elastic tabstops? It serves no purpose in any mainstream programming language, yet is parsed as valid whitespace in all of them, AFAIK.

This would mean that the use of elastic tabstops is no longer an externalized convention (e.g. "this file was formatted with elastic tabstops, please turn them on") but something you opt in to on a case by case basis.

Existing text editors usually display a glyph or a single space in place of a vertical tab. This is not ideal, but a small price to pay, IMO.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.