== 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 http://www.joelonsoftware.com/items/2006/07/03.html]]: > [[Nick Gravgaard http://nickgravgaard.com/elastictabstops/]]: "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 http://nickgravgaard.com/elastictabstops/]]: > 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
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.