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)

  • 5
    This would be a great question for ux.stackexchange.com
    – JonnyBoats
    Commented Feb 28, 2012 at 11:43
  • 11
    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. Commented Feb 28, 2012 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... Commented Feb 28, 2012 at 15:09
  • 3
    @ChrisBurt-Brown That's always a risk, yes. IntelliSense has its pitfalls too, like subsituting text when you didn't want it to. Overall, however, IntelliSense in C# a big fat win. Commented Feb 28, 2012 at 15:13
  • 4
    I want this in notepad++...I want this now
    – Zelda
    Commented Feb 28, 2012 at 18:03

12 Answers 12


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.

  • (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. Commented Feb 28, 2012 at 16:47
  • 3
    @romkyns: As for many things, it takes either one quiet insider or a thousand voices screaming at the gates.
    – haylem
    Commented Feb 28, 2012 at 17:05

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.

  • 14
    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
    Commented Feb 28, 2012 at 14:58
  • 10
    @Timwi:The question was to list drawbacks. I did. Commented Feb 28, 2012 at 15:04
  • 16
    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. Commented Feb 28, 2012 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
    Commented Feb 28, 2012 at 15:33

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.

  • 11
    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
    Commented Feb 28, 2012 at 12:12
  • 14
    @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. Commented Feb 28, 2012 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. Commented Feb 28, 2012 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
    Commented Feb 28, 2012 at 13:16
  • 7
    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
    Commented Feb 28, 2012 at 15:10

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.


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 ):

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.

  • Agreed. Nick's implementation doesn't work for languages like Python very well at all. Commented Feb 28, 2012 at 20:08
  • 3
    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. Commented Feb 28, 2012 at 20:17
  • 2
    @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
    Commented Feb 29, 2012 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. Commented Feb 29, 2012 at 8:07
  • 2
    Oh, good point. Hmm... maybe you could double-indent the arguments? So then wibble() would only have a single indentation and therefore wouldn't be aligned with the function arguments?
    – Ajedi32
    Commented Feb 7, 2014 at 17:39

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.

  • 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. Commented Feb 28, 2012 at 16:15
  • 1
    @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. Commented Feb 28, 2012 at 16:22
  • 1
    @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. Commented Feb 28, 2012 at 16:25

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.

  • I've cleared the comments as they were descending into insult.
    – ChrisF
    Commented Feb 29, 2012 at 16:49
  • 2
    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
    Commented Feb 7, 2014 at 17:25
  • "Having to install yet another tool..." isn't a good enough argument... As if there aren't enough tools being used already.
    – Milind R
    Commented Dec 4, 2014 at 16:53
  • @MilindR Whether you consider it a good enough argument or not, it's the reason why (at the time three years ago) I would have no interest in this. There being a lot of tools used that do something useful isn't a reason to add another one that, really, doesn't add anything to your environment.
    – TZHX
    Commented Jan 26, 2015 at 10:29
  • Attitudes like this are why companies like MS decide to force users into new UXes ... I shudder to think what would happen if the same attitude were applied to the floppies -> CD transition.
    – Milind R
    Commented Jan 26, 2015 at 11:42

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.


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.

  • @haylem: Thanks for the feedback. I’ve removed the reference to C/C++.
    – Timwi
    Commented Feb 28, 2012 at 21:02
  • @JonPurdy: Thanks for the feedback. I’ve removed the reference to C/C++.
    – Timwi
    Commented Feb 28, 2012 at 21:02

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.


I just tried out jEdit's implementation of elastic tabstops, which works amazingly well with the programming languages in with which I'm familiar (primarily HTML/XML and C-like languages). With Python code, however, here is how it rendered (spaces used in place of tabs to illustrate how things align):

def foo(x):
             '''<1 tab before the docstring.
No tab       <tab
No tab       <tab
             <tab  <another tab
             <tab  <another tab
             if 1 or 2:    #<Tab before this comment
                           yield True

For a language like Python that relies upon spacing, this is a deal-breaker unless you disable the functionality provided by elastic tabstops. Editors like Vim and Emacs make disabling most kinds of functionality simple if you know the name of the option and how to disable it, but this functionality would be required to be disabled for code like the above.

That being said, it's great for x86 ASM, C, C++, Go, XML, HTML, and others that don't rely on whitespace so much:

import (
    "fmt"    // We love formatting functions.
    "io"     // Because I/O is useful.
    "os"     // Can't open a file without os.Open!

type Foo struct {
    Field1              int          // This is properly aligned
    ReallyLongField2    string       // with this.
    privateField        io.Reader    // Elastic tabstops are great for Go.

I will say that Lisp dialects such as Scheme have their own conventions that would also make elastic tabstops render "ugly" code. If I change my tabstop settings to match the convention of 2 columns and insert tabstops at unusual places (between a function and its arguments):

(let loop ((n 1))
  (if  (> n 10)
        (cons  n
               (loop (+ n 1)))))

vs. the more readable:

(let loop ((n 1))
  (if (> n 10)
      (cons n
            (loop (+ n 1)))))

Granted, this one isn't as bad as the Python example, but it definitely reduces readability of the code. While I very much enjoy the functionality when coding in something like C# or C++, I abhor the functionality when coding in a language like Python or Scheme where whitespace is functional and/or visually helpful. Elastic tabstops were created specifically to be helpful without requiring a separate indentation utility, but clearly it's not meant for all programming languages.

  • 1
    At least the lisp example is just using elastic tabstops wrongly. If you want something aligned, you use the same number of tabs from the start of the line on it. You don't just use the same inconsistent number of tabs for the lines that you had to use previously just to work around the inelastic tabstops you had before.
    – mtraceur
    Commented May 29, 2020 at 5:05
  • 1
    I also don't see any real issue with the Python example - why are you tabbing a line comment - just use two spaces unless you mean that you want it aligned. That's what tabs mean - a desire for alignment (like in a table) - and elastic tabstops just give you a 1-to-1 correlation between number of tabs in the line and which (dynamically positioned) column it aligns with. If you tab your comment, you are saying you want it aligned with the next line's thing one tab over. If you don't tab the comment, it won't do that.
    – mtraceur
    Commented May 29, 2020 at 5:09
  • But I vote +1 on this answer because it reveals that one problem with elastic tabstops is that people will just use their existing tabbing habits (which only made sense for fixed tabstops) and then see it as a problem with elastic tabstops rather than take the few minutes of thought to realize how elastic tabstops let them use the tab key to achieve what they want even more efficiently.
    – mtraceur
    Commented May 29, 2020 at 5:13

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.

  • 2
    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. Commented Feb 28, 2012 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. Commented Feb 28, 2012 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. Commented Feb 28, 2012 at 22:08

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