Elastic tabstops - a better way to indent and align code

Introducing elastic tabstops in gedit

I've been pretty quiet for a while, but that's because I've been busy hacking gedit to support elastic tabstops. I've also made a plugin for gedit that allows users to work on projects which use spaces for alignment. To see a screencast of it in action or to download it, visit nick-gravgaard.com/elastic-tabstops/gedit

Posted on Monday, 2007-05-28 at 16:31 UTC


Monday 2007-05-28 18:30 UTC
Don Kirkby
Looks good, glad to see you're still plugging away. Do you know if anyone has started working on an eclipse plug-in that implements elastic tabstops?

Monday 2007-05-28 18:31 UTC
So when's the Emacs minor mode coming? :)

Tuesday 2007-05-29 09:51 UTC
very nice, thanks for sharing!

Tuesday 2007-05-29 12:42 UTC
Don Kirkby: Thanks. I'm not sure if anyone is working on doing it in Eclipse, but someone entered it in Eclipse's bug tracking system. See https://www.eclipse.org/bugs/show_bug.cgi?id=149603

Tuesday 2007-05-29 12:43 UTC
anonymous: I've heard numerous people talking about implementing it in Emacs but I haven't seen anything concrete yet. If you subscribe to the RSS feed I can keep you informed of any developmets...

Tuesday 2007-05-29 12:44 UTC
Jan: Thanks for the kind words. It's always nice to get this kind of feedback.

Tuesday 2007-05-29 16:44 UTC
Elastic tabstops seems overly complicated to me. I think Salvatore Iovene has a good solution: "The solution of this problem is to simply just use what ever you want for indenting, but use spaces for aligning. Indenting must only be that left margin that you give to some lines, but it’s not to be confused with alignment." Personally, I prefer using tabs to indent, because some people like deeper indenting than others, and tabs allow that, and I agree with Salvatore on using spaces for all other aligning. Tabs suck for aligning. See Salvatore's entire article here: http://www.iovene.com/tabs-vs-spaces-the-end-of-the-debate/ (Gee. Now bloggers have me solving their kids' math homework. :) )

Tuesday 2007-05-29 17:43 UTC
Tim: I don't think this is overly complicated. I do think it strange that we still use a mechanism based on the workings of the humble typewriter in this modern age (tabstops at a fixed number of monospaced characters apart). Anyway, Salvatore says "So, in the end, it doesn't matter whether you use TABs or space, for indenting, as long as you use just spaces for aligning." You can't use tabs for indenting and spaces for aligning. Copy the following code into a monospaced editor: if.(true).{........//.comment [TAB]doFunction()..//.comment }..................//.comment if.(true).{........//.comment [BIGGERTAB]doFunction()..//.comment }..................//.comment The comments no longer line up.

Tuesday 2007-05-29 19:50 UTC
I agree that example does not line up but I have never tried to spread a multi-line comment across code like that. It looks like a post-it note on a print out. In my mind (which is not like everyone else) multi-line comments belong above a section of code and not at the end of the lines. No wonder you are having such issues. I do not think // was designed to be a structure for multi-line comments. Use /* */ instead. This won't fix your issue but it requires multi-line comments to be between lines of code, as I agree they should be.

Tuesday 2007-05-29 20:19 UTC
Tim: I don't do that sort of thing either, but I've seen all sorts of strange code during my career. I mention it just to highlight a flaw in the "tabs for indenting and spaces for aligning" argument. IMHO Elastic tabstops offer significant advantages, the main one being that we are now free to indent as much or as little as possible and we don't even have to think about it.

Tuesday 2007-05-29 20:41 UTC
Eventually we will all use a DTP app or our code is entirely XML behind the scenes, so we can pretty up the code however we like without confusing the compiler. I'm not against progress. Why stop with elastic tabstops? Let's do it now. Some line wrapping would be good here.

Tuesday 2007-05-29 21:08 UTC
Alain Roy <roy AT cs DOT wisc DOT edu>
I liked the idea of converting between elastic tab stops and spaces automatically, until I realized that it would mess with my source code control system. If I add a single character, it might change many lines in a file and make the apparent diff much larger than necessary.

Tuesday 2007-05-29 22:03 UTC
Alain Roy: I suppose if you had modified the file normally you would have had to add extra spaces to the other lines if you wanted things to continue to line up, so you would have the same problem. Besides, most diff tools can be told to ignore whitespace...

Thursday 2007-08-09 21:26 UTC
Daniel Lyons <fusion AT storytotell DOT org>
I'm with anonymous, wanting an Emacs minor mode so I can use a pretty font to edit my code. :)

Tuesday 2007-10-16 15:27 UTC
Matej Cepl
Any ideas? [matej@hubmaier mkfile]$ gedit mkfile.c Gtk-Message: (for origin information, set GTK_DEBUG): failed to retrieve property `GtkTreeView::odd-row-color' of type `GdkColor' from rc file value "((GString*) 0x8db060)" of type `GString' ** (gedit:17859): WARNING **: /home/matej/.gnome2/gedit/plugins/libelastictabstops.so: chybná t&#345;ída ELF:&#8239;ELFCLASS32 ** (gedit:17859): WARNING **: Cannot load plugin 'Elastic tabstops' since file '/home/matej/.gnome2/gedit/plugins/libelastictabstops.so' cannot be read. ** (gedit:17859): WARNING **: Error activating plugin 'Elastic tabstops' Traceback (most recent call last): File "/home/matej/.gnome2/gedit/plugins/elastictabstopsconverter.py", line 305, in convert_to_elastic_tabstops_action self.tabsize = window.get_active_view().get_tabs_width() AttributeError: 'gedit.View' object has no attribute 'get_tabs_width' Traceback (most recent call last): File "/home/matej/.gnome2/gedit/plugins/elastictabstopsconverter.py", line 305, in convert_to_elastic_tabstops_action self.tabsize = window.get_active_view().get_tabs_width() AttributeError: 'gedit.View' object has no attribute 'get_tabs_width' [matej@hubmaier mkfile]$ ls /home/matej/.gnome2/gedit/plugins/libelastictabstops.so /home/matej/.gnome2/gedit/plugins/libelastictabstops.so [matej@hubmaier mkfile]$ ls -l /home/matej/.gnome2/gedit/plugins/libelastictabstops.so -rwxr-xr-x 1 matej matej 46230 2007-09-16 16:29 /home/matej/.gnome2/gedit/plugins/libelastictabstops.so [

Saturday 2008-10-18 07:24 UTC
Salvatore Iovene <salvatore DOT iovene AT gmail DOT com>
Nice to see my name involved in this discussion. I think that althought Nick's example is something people don't do very often, and, either way, don't really NEED to do, I find that elastic tabstops are a brilliant solution, and I would adopt them myself if there only were Vim plugins :-)

Saturday 2008-10-18 07:27 UTC
Salvatore Iovene <salvatore DOT iovene AT gmail DOT com>
Matej, check your gedit preferences and make sure you're not converting tabs to spaces automatically.

Tuesday 2013-02-19 12:40 UTC
Jozif <web AT civilization DOT ca>
Hey, I was just wondering if you know if there's a way, other than the right arrow, to reumse typing outside of the ending brackets that Bracket Completion puts in? If I'm in my typing trance, I *really* don't want to have to move my hand over to the right arrow. It just breaks up my typing real good, and if there's no other way to escape the brackets, I may just have to disable the plugin. Thanks for your time oh, and that theme tip, too

Comments are closed.