What are the drawbacks of elastic tabstops?

Question

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.

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)

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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.

Answer 10

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.

Answer 11

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.