2006-07-05
On tabs
I rarely have violent visceral reactions to things. But I have a few hot buttons, and here's one of them. Quoting from Joel Spolsky's summary:
Nick Gravgaard: "Rather than saying that a tab character (a "hard tab") 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..."
Wrong. Wrong wrong wrong. The core wrongness is visible in a single line in the original:
The solution then is to redefine how tabs are interpreted by the text editor.
The problem is that it's not just your text editor that matters.
Actual real tab characters have a well defined meaning, enforced by
terminal emulators, pagers like less, many editors, your browser (in
<pre> text), and programs that print things out. If you decide, like
Humpty Dumpty, to make Control-I mean something else for you, you have
adopted an entirely quixotic quest and I want you nowhere near anything
I ever have to read.
(Because I certainly do not want to have to use your editor, assuming it is even available on my platform, to read your text in a way that makes it look decent and comprehensible.)
This need not cramp anyone's creativity, since I don't care what the tab key on your keyboard does and I don't care what mixture of characters your editor uses to embody your favorite indentation (provided it agrees with the rest of the world on what a Control-I character does). This leaves a great deal of room in the user interface, as GNU Emacs has been demonstrating for years.
(If you want to be able to edit Unix Makefiles, your editor had better be able to create and preserve real tab characters. Arguably this was a mistake way back in V7, but we're certainly stuck with it now.)
From this, you may gather that my opinion of vi's tabstop setting and
the corresponding GNU Emacs tab-width variable is rather low.