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 solution then is to redefine how tabs are interpreted by the text editor. Rather than saying that a tab character will move the cursor until the cursor's position is a multiple of N characters, 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 (not a new idea - see Smalltalk).

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. Bigger sizes are even better (if you can get your co-workers to agree). 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.

#include <stdio.h>

int someDemoCode(	int fred,
	int wilma)

{

x();	/* try making	*/
print("hello again!\n");	/* this comment	*/
makeThisFunctionNameLonger();	/* a bit longer	*/

for (i = start; i < end; ++i)

{

if (isPrime(i))

{

++numPrimes;

}

return numPrimes;

}

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

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.

Gedit

I have written 2 plugins for Gedit, one that provides the main elastic tabstops functionality, and another that allows users to convert files that use spaces for alignment.

Click to watch a screencast of gedit with elastic tabstops

Download the plugins (and optionally the c code for the main plugin).

Extract the files to ~/.gnome2/gedit/plugins

Delete the libelastictabstops.x86_32.so or libelastictabstops.x86_64.so file so the only .so file remaining is the one that matches your machine's processor architecture. Rename it to libelastictabstops.so

Optionally use the following commands to set the minimum width and padding width values:

gconftool-2 --type int --set /apps/gedit-2/plugins/elastictabstops/minimumwidth 40 gconftool-2 --type int --set /apps/gedit-2/plugins/elastictabstops/paddingwidth 16

Activate the plugins in the preferences dialog.

The term "elastic tabstops"

Please note that this functionality is called "elastic tabstops", not "elastic tabs". One of the reasons there is so much confusion about the whitespace issue is that people get the terminology mixed up. When you hit the tab key most editors will either insert a tab character or some space characters in the current file. When an editor comes across a tab character it takes the characters that follow it and graphically aligns them with a tabstop. "Elastic tabstops" are all about moving these tabstops so that vertically adjacent "cells" have the same width. A tab character is just ASCII byte 09, and there's not much that's "elastic" about that!

up to nickgravgaard.com/