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 - move tabstops to fit the text between them and align them with matching tabstops on adjacent lines
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).
This animated diagram shows how the elastic tabstops mechanism aligns 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
Sorry for writing this in Java, but it was the only sensible way of doing it in 2006. Anyway, 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 and pasting a tab character or download the jar file (source code included) and run it outside the browser.
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 HTML's designers considered tables I'm sure they never thought about 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.
While editors which haven't yet implemented the elastic tabstops mechanism may not align some text properly in files where tabs were used with elastic tabstops, the problem isn't that bad. All leading tabs (indentation) will be okay, and the chances of text not aligning correctly diminishes as the width between tabstops increases. So 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 suggest using tabs with fixed tabstops every 8 characters (or more) across. Alternatively co-workers 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.
- My Java Swing applet
- My Gedit plugin
- Code Browser by Marc Kerbiquet
- Inform 7, an IDE for programming interactive fiction
- An implementation for Scintilla
- MultiMarkdown Composer 2 (OS X only, so untested)
- Google's Go programming language (made by Rob Pike and Ken Thompson (amongst others) who were also responsible for UTF-8) uses elastic tabstops in it's "tabwriter" package.
Implementations in development
- My Visual Studio plugin will soon be available to a small number of users in the form of a limited public beta. Email "me" now at this domain if you want to be on the list.
- My Eclipse plugin is currently stalled until this bug gets fixed. Go and vote for it.
- Browser based text editors are currently stalled until it becomes possible to set tabstops at non-uniform positions. I had a discussion about this on the W3C www-style mailing list here. We seemed to settle on a solution where the 'tab-size' property would change to optionally take a list of px values instead (ie tab-size: 30px 20px 26px 42px; with the last value repeating), but there needs to be an implementation before the W3C spec can change. This would also mean Word style draggable tabstop markers could be added to browser based word processors. I hope that someone from Microsoft, Google or Adobe (all of which have a browser based word processor) will work on an implementation.
The name "elastic tabstops"
I've noticed some people have mistakenly started calling this mechanism "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 can a character be elastic?
Wikipedia editors: Please note that the plural form is used to name this mechanism - the singular makes no sense. Elastic tabstops is a mechanism for aligning pieces of text. To align means "to form into a line" and a line consists of at least 2 points. I notice, for instance, that you haven't changed the names of "counting rods", "Indian numerals", "checks and balances" or "scissors" to the singular form, presumably because they're the names of mechanisms and don't make sense in the singular (as with my project). Please use the name I chose for my invention.
up to nickgravgaard.com/
The elastic tabstops mechanism was invented by Nick Gravgaard in the summer of 2006. All text and images on this page are copyright © 2006-2013 Nick Gravgaard and licensed under a Creative Commons Attribution 3.0 Licence. This page was first uploaded on 2006-07-02 and last updated on 2013-03-16.