Elastic tabstops - a better way to indent and align code

Intro - the status quo sucks

Since the days of the character mapped display, programmers have argued over whether tabs or spaces should be used to line up text. While both strategies can be used if all of a project's programmers can agree on how many spaces wide a tab should be, experience has taught us that this is not always the case. Even if all of the programmers working on a project are diligent enough to stick to only using tabs or spaces and have tabs set to the agreed number of spaces, there is still a problem if any programmers wish to use modern proportional fonts (because a space is no longer the same width as every other character).

The reason why we have not yet settled conclusively on either tabs or spaces is that both camps can point to problems in the others' approach. The truth is that both are right to be critical - both solutions are inadequate as neither allows different programmers to look at the same file and have their indentation and columns as wide or as thin as they'd like without text getting misaligned. Using spaces to align columns is obviously a kludge, but tabs as they stand now are broken.

The solution - tabstops that expand or shrink to fit their contents

For as long as we continue to define each tabstop as being a multiple of N characters we will never be able to solve this problem satisfactorily. The problem is that we're using tabs and spaces to format text for aesthetic reasons rather than treating them semantically - tabs are for indenting and aligning text, spaces are for separating keywords.

The simple solution is to redefine how tabs are interpreted by the text editor. Rather than saying that a tab character places the text that follows it at the next Nth column, we should say that a tab character is a delimiter between table cells in a manner more reminiscent of how they're used in tab separated value (TSV) files. Seen in this light, we can see that space aligned files are analogous to the old fixed width data files, and we all know the advantages that delimited files have over those. For one thing, you can use sed or other tools to substitute strings in files and everything will still line up when you load them in the editor. Another advantage is that proportional fonts can now be used (in itself not a new idea - see Smalltalk, Oberon and Plan 9's Acme).

animation showing code in an editor with elastic tabstops being edited

This diagram shows how elastic tabstops align text. A tab character is represented as a vertical line.

Each cell ends with a tab character. A column block is a run of uninterrupted vertically adjacent cells. A column block is as wide as the widest piece of text in the cells it contains or a minimum width (plus padding). Text outside column blocks is ignored.

Try it right now

This browser does not have a Java Plug-in.
Get the latest Java Plug-in here.

In some browsers, pressing tab will switch to the next focussable part of the page, rather than sending the event to the applet. If that happens to you, try copying a tab character and pasting it. If that's too annoying or you have any other problems, you can download the jar file (source code included) and run it outside the browser instead.

Keep it simple, stupid!

This solution is as simple as possible, and is arguably simpler conceptually than the old mod-N model (although a bit more work computationally, which is probably why they went with the mod-N system back in the 1970s). When the designers of HTML were figuring out how tables should work I'm sure they never entertained the idea of reimplementing the old mod-N model, and no one would ever say that HTML tables are complicated or in any way intelligent. The elastic tabstops mechanism is the same - as simple as possible, but no simpler. Just like the mod-N model it seeks to replace it doesn't care about what the text between tabs is, and nor should it.

Every so often someone will show how they can make code align in a funny way by laying out their code just so, and then go on to come up with a complicated context sensitive and language dependant scheme which fixes that particlar edge case. A better and simpler solution is simply "don't do that, then". Existing code conventions evolved in an environment where displays were character based and tabstops were every N columns. It's not hard to imagine new conventions evolving in a new environment where proportional fonts are possible and text always stays lined up properly.

Forwards compatibility

While editors which have not implemented elastic tabstops yet may not align some text properly in files where tabs were used with elastic tabstops, the problem is not that bad. All leading tabs (indentation) will be okay, and the chances of text not aligning correctly diminishes as the width between tabstops increases. For this reason, if you plan on switching to elastic tabstops in the future, and wish to choose a code style with that in mind (to use now), I would suggest using tabs with fixed tabstops every 8 characters (or more) across. Alternatively different developers on the same team can use tabs with fixed tabstops of whatever size they like as long as no one tries to line up text for anything other than indentation.

Current implementations

The term "elastic tabstops"

I've noticed some people have mistakenly started calling this functionality "elastic tabs" rather than "elastic tabstops". Tabs and tabstops are different things. They're not synonymous and you can't abbreviate one to form the other. Besides, how could a tab character ever be elastic? Also note that the plural form is used as the mechanism aligns text on multiple lines. Please use the right name.

up to nickgravgaard.com/

Elastic tabstops were invented by Nick Gravgaard in the summer of 2006. All text and images on this page are copyright © 2006-2010 Nick Gravgaard and licenced under the GNU Free Documentation Licence. This page was first uploaded on 2006-07-02 and last updated on 2010-05-27.