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...
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.