Hacker News new | past | comments | ask | show | jobs | submit login
Elastic Tab Stops: A Better Way to Indent and Align Code (nickgravgaard.com)
82 points by mojombo on Oct 15, 2008 | hide | past | favorite | 40 comments

I remember reading this several years ago. It's not something that is 100% implemented by configuring emacs or vi properly: read the entire article slowly.

I'm surprised I haven't heard any Python coders piping up. We pick spaces or tabs, and stick with it; otherwise, our code doesn't run. Mixing tabs and spaces is pure evil.

I prefer spaces, because a space is a space and will display as exactly one space in any text editor.

> I'm surprised I haven't heard any Python coders piping up.

Because either indentation is a non-issue for you or you don't use Python.

Any decent editor solves this problem to the 98-99% mark. There's lots more interesting things to do than dick around with that 1-2%

Python forces you to keep your indentation correct and sane so it's never so whacked you need special tools to deal with it.

Proper indenting is subconscious like other languages ';' at end of line or parens around expressions in if/for. That is when it isn't automatically handled by your editor...

Well, any editor with fixed width fonts, which the author of the article would like to move away from.

Even if you use tabs, the Python compiler will convert a tab to 8 spaces internally.

> While both strategies can be used if all of a project's programmers can agree on how many spaces wide a tab should be

A better strategy that works just fine for a lot of developers (e.g. Linux kernel crowd) is to use tabs to indent the start of the line only. No tabs inside of the line, only spaces. Very simple and works really well.

How many people here use tabs? I find them pure evil. If I press left/right arrow, I want to move one character/space. Not 4/8.

edit: obviously I setup tab to insert 4 spaces etc

I prefer tabs way more than spaces. It's faster to indenting back and better for search regexps, quite an important point for me. With Vim it's easy to retab a text if needed anyway.

the indenting commands work the same way in vim with tabs or spaces -- either select a visual range and hit >, or hit >a} to indent a brace delimited block, or... well, you know the drill. the > or < compose in the same way you'd expect any other vim command to do.

With vim you need sts. It lets you you backspace over spaces just like tabs. Now I never need tabs anymore.

I don't understand your point about search regexps.

Thanks for the softtabstop tip, that was a life saver as I'm forced to used spaces. For the regexps I'm used to search for tabs to distinguish lvalues but two spaces are the same for that patterns.

Awesome built in demo, made it way more interesting to get to play around with the idea a bit.

This may just seem silly and superficial, but I find the demonstration picture with colored indenting would actually be quite useful. Perhaps not coloring the code itself but more the number of tabstops until the code.

This is even worse than forcing people to set their tab width to a certain value to read your code. If their editor isn't set up for it, they don't just have to change a setitng; if they're lucky, they just have to install a plugin, but if there isn't one available, they have to change editors entirely.

Or live with ugly code. Like they probably did before.

But you're right, this is a thing where I also see a big problem. It's not downward compatible.

Actually I find the code produced by this elastic tabstop to be far uglier than the alternatives.

I have been using this is gedit and it really does make a world of difference. I used to emulate which just led to greater overhead and often poor code formatting.

I'm normally very anti-tabs, but if vim supported this I'd switch in an instant.

If you watch the screencast, it offers an option to save as spaces, so the "I hate tabs" argument is kind of irrelevant. Unless you also hate tabstops.

Has anyone tried this with large source code files? I suppose, in the long run, if your source has too big of an overhead to implement this, you're probably doing it wrong, especially considering the relative power of computers to the amount of RAM raw text should take up.

Mathematica has very nice auto-tabbing; not exactly what's shown here but something very similar, and even better as it goes beyond tabs: it also makes changes on the font depending on context.

TextMate. Now.

TextMate already has indentation issues. Why is it that every time I paste something it indents it one more tab?

i.e. if I paste something 3 times I end up with something like this:

    Hello world
        Hello world
            Hello world

Unfortunately, not really


Who else has noticed that textmate has stagnated from 2006-2008

most textmate dev nowadays is being done in bundles. while the elastic tabs thing doesn't work quite right in textmate, textmate's tabbing (soft-tabs to convert tabs to spaces, backspace to go back a 'tab', autoindent based on syntax conventions) is pretty satisfactory.

one thing it doesn't do that looks REALLY appealing with elastic tabs is multi-tabbing, especially to appropriate spacing on multiline parameter lists. i'll add 'write a bundle to do this stuff' to the long list of projects that fall behind the startup.

Agreed, but for Coda.

thanks mojombo!

A better way to indent and align code: Use emacs and tell it to indent in any way you want.

PS. Make sure you have (setq-default indent-tabs-mode nil) somewhere in your .emacs

Yeah! It is so easy to line up columns in emacs. Just hit tab and emacs takes the cursor to the correct column.

Exactly. I'm honestly surprised there are still editors that don't do this.

That was my thought too: a cute hack in 2008 for a problem that was cleanly solved a quarter century earlier by software that remains popular to this day. I know it's easy to laugh at stuff like this, and I'm sure someone will use this and like it. But still, guys: software development is a mature field. The realm of useful tools for editing code is pretty tapped out. The good ideas lie elsewhere.

That's a bit reminiscent of "you just need 512k of RAM!"

This elastic tabs thingy, REINDENTS everything based on what you type on the next line... keeping your code formatted in consistent blocks.

Honest question: Is that what emacs does?

Well, emacs lets you hit tab anywhere on a line, at which point it reindents the line to the appropriate depth, depending on the syntax of the current and preceding lines. I'm pretty sure that most of the modes I use don't look at lines after the current line when performing indentation, but I'm not sure there's any reason why they couldn't.

If you want to reformat an entire block of code in this way, you can set a region (the emacs equivalent of "selection") and then press Ctrl-Meta-\, which stands for "indent-region". Then either the whole region will magically become properly indented, or emacs will yell at you because your XHTML syntax is broken (at least, that's what just happened when I tried this in XHTML mode. Every major mode can be slightly different.)

I know that emacs supports all the indentation tricks shown in this guy's example ... except that I don't know about the end-of-line comments. I never use end-of-line comments.

That sounds like it is simply indenting the whole line... not reformatting the actual block... i.e. respacing internally within the line. Which is what the elastic tabstops is doing.

It's not simply realigning each line. It's reformatting the entire block, realigning ALL tabstops within the lines, so that blocks of text are all positioned within a grid.

"simply indenting the whole line" </quote>

"the package cc-engine (including its cc-* helper packages) bundled with GNU Emacs 22 is approximately 27,000 lines of lisp code, and it's all dedicated to indentation." </quote> http://steve-yegge.blogspot.com/2008/03/js2-mode-new-javascr...

It seems realigning each line is not that simple.

That's hardly the point now is it? You knew exactly what the expression I used means in this context.

I've no idea what "simply indenting the whole line" could mean other then "simply indenting the whole line". :)

Elastic tab stops is actually orthogonal to this. Aligning elastic tab stops is easy (minor complications caused by blank lines), knowing how many tab stops to put in is where those 27 000 lines of lisp come in.

I use align-regexp for equal signs and end-of-line comments occasionally.

In some modes (e.g. C mode, plain text mode, several others), yes, though it's usually turned off by default. (I find it really distracting.) Usually, it automatically indents when you type a newline, add an opening or closing brace, an if statement, etc. The re-indent-as-you-go behavior seems to be used most in C mode, because you can specifically configure your indent style (http://en.wikipedia.org/wiki/Indent_style).

Most modes also have a command such as c-fill-paragraph that re-indents the chunk of code (e.g. function body) that the cursor is in. (Emacs refers to this behavior as "filling", so that's what to search for.) I think people use this pretty often - it's alt-Q by default.

The automatic indentation is quite good for some modes (C, Lisps in general, Python, OCaml, Lua, probably many others), but not always perfect (haskell-mode comes to mind). I think the important thing is that Emacs provides a lot of hooks for building mode-specific indentation-control functions and is not terribly difficult to extend.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact