Elastic tabstops - a better way to indent and align code

An update and a request for help

Well, it's been a while so I figured I should give everyone an update. Just over a year ago I released a plugin for Gedit. It works fine, but there are a couple of issues with it, the main one being that Gedit currently only exists on Linux and other X based platforms, and no ports exist for Windows or Mac OS X. The second issue is that it uses an inefficient yet relatively straight forward algorithm which recalculates everything every time the text changes (like my Java demo). As a result I decided to make a better solution that is cross platform and caches the information it needs properly. I've decided to use PyGTK (the Python bindings for GTK) to make my own editor and I hope to have something I can share with you soon. Once my Python implementation is finished I'll also be able to replace the C based Gedit plugin with something which is faster and less work for me to maintain. Also, to make it easier for people to see the idea in action I've reworked my Java demo on the main elastic tabstops page so it can be embedded in the page as an applet.

In other news, my job was outsourced a couple of weeks ago, and while I don't think I'll have too much trouble finding another one, I thought I'd use the time off as an opportunity to see if I can advance my goal of getting elastic tabstops adopted in a major editor. I believe that the concept of elastic tabstops is a real improvement over the status quo, as presumably do some Visual Studio users, Visual Assist X (a Visual Studio add-in) users, Slashdot editors, Eclipse developers, ex Microsoft Excel program managers and many others. Since developers for Microsoft's platform pretty much all use Visual Studio exclusively, it occurs to me that elastic tabstops could be adopted without developers for the platform suffering from the chicken and egg problem that developers on other platforms may face. So, if you work at Microsoft (or know someone who does) now would be a great time to speak to someone on the Visual Studio team about getting them to help me add this feature.

Let's see if we can make things better for programmers.

Posted on Wednesday, 2008-10-15 at 16:20 UTC

15 comments

Thursday 2008-10-16 07:49 UTC

Simon Rivada <simon AT liebmi DOT ch>

I would just love to see this adopted in VIM, it would bring me back to tabs after years and years of 4-space indent (ts=4).

Thursday 2008-10-16 08:36 UTC

Josh

Personally, I think you're most likely to have success with Eclipse; the chicken and egg problem is valid, but platform uptake will be a lot better for open tools with developers who like experimenting. VS.net -- well, those guys have coding standards and well paid managers.

Thursday 2008-10-16 08:49 UTC

Lionel Barret <lionel AT gamr7 DOT com>

seconded on the vim or emacs integration. This should be doable quite easily and help you refine your algo/prototype.

Thursday 2008-10-16 09:10 UTC

Richard <rnhurt AT kangaroobox DOT com>

VIM FTW!

Thursday 2008-10-16 10:24 UTC

Paul K <paulrkeeble AT googlemail DOT com>

Second on the eclipse integration. If it can be done as a plugin you have a good chance of this getting adopted more widely. Doing your own editor is a waste of time, if you get the major IDEs and text editors then it will eventually become the standard.

Thursday 2008-10-16 13:05 UTC

Nick

For those of you asking for an Eclipse plugin: I agree. Eclipse is widely used and cross platform, making it an obvious candidate. However people have already asked for this to be added to Eclipse in that project's bug tracking system - see here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=149603 "Before we can continue on this bug we have to wait for bug 4866. We are currently not planning to push for bug 4866 since we don't intend to work on this item for now. Should someone consider to commit resource for this enhancement we can start negotiating with SWT." Basically, for elastic tabstops to be added to any editor, it's widget needs to allow different non-uniform tabstops on different lines. SWT doesn't support that at the moment.

Thursday 2008-10-16 15:37 UTC

I'm pretty sure source insight has had this for ages...

Thursday 2008-10-16 17:58 UTC

Nick

P: No, I had a look and it doesn't look like Source Insight has elastic tabstops. In the future, please check before making spurious claims like that.

Friday 2008-10-17 06:54 UTC

Professor_k

I'll vote for perfect JetBrains Resharper tool for the MS VS. It would be definitely easier to find out common language with JetBrains developer, that with MS, while JetBrains is de facto must have tool for Visual Studio developer.

Friday 2008-10-17 14:11 UTC

Steve R <tabs AT opensauce DOT de>

I love your idea! (and can't believe you've had it published for 2 years already Personally I pipe sections of my code through a home-grown perl-script which can be used to align anything that matches a user-provided pattern. This has the advantage that -I- can specify exactly which bits of code are to be aligned, and if the formatter gets it wrong I can still adjust the spaces if needed. After that the formatting doesn't change until I explicitly filter that block again. Also, since the result uses spaces only, it looks the same for everyone. I don't think I'd want that to happen automagically and without a way to change the results. The "consecutive lines containing tabs" is a good starting point, but I can think of several situations in which it really wouldn't be appropriate. Building an AI system to recognise all possible patterns and desired outcomes would of course be infeasible. The other problem that would still exist is "how does it look when someone else opens the file in their favourite editor[tm]?" Sorry to be the devil's advocate :-) PS: I'm an absolute vim fan! PPS: if there's interest in my pipe-through-formatter I'll clean it up and publish it.

Wednesday 2008-10-29 15:59 UTC

John S <john AT kassett DOT net>

This is something I've become a serious proponent of in a matter of seconds. It's brilliant and I want it in my Visual Studio right now!

Wednesday 2009-01-07 19:29 UTC

Troels Thomsen <troethom AT gmail DOT com>

I have forwarded your shout-out to an employee of the Visual Studio Project & Build team. Coincidentially he has worked on a another specification to the same problem, so he will pass the information to the right people, and hopefully we will get support for elastic tabstops one day. Hopefully sooner than later.

Sunday 2009-02-08 20:43 UTC

Mick Pearson <mick DOT pearson AT wildblue DOT net>

I spoke with Nick a while back regarding some questions I had before making e-tabstops the default way of doing text displays with a text subsystem I'm involved in implementing. Well it took a little while longer than I'd guessed before proper tab coding came up after a re-write, but I think this is finally the next item up to bat. I'm just curious if anyone could outline the current best understanding of this concept at this point, because there are no formal specifications so far. I'd really prefer the concept be implemented uniformly. Also I don't think "upconverting" files should be necessary. Though it might help further prettify some things for some people. My personal plans atm are to implement the tabbing as described, but I think it would be useful were a shift+tab possible - the behavior of which would be to ignore all previous tab layouts in that column. This would make the system logically air-tight I think. If this sounds like a good idea. I'd like to ask everyone how the shift-tab could be encoded, so it might appear harmlessly if unrecognized under as many circumstances as possible. Some vestigial non-printing character in front of or after a tab perhaps? Also the same sort of advice for Unicode would be informative.

Sunday 2009-02-08 20:56 UTC

Mick Pearson

PS: Are reverse tabs (shift+tab) ever used in text editors? I think I recall some behavior before... probably with the MSVC ide. In any case, please let us know if shift-tab is already a popular key binding.

Thursday 2009-02-26 20:02 UTC

Leif

"Basically, for elastic tabstops to be added to any editor, it's widget needs to allow different non-uniform tabstops on different lines. SWT doesn't support that at the moment." It seems useful to distinguish two behaviours: 1. coherent alignment of contiguous lines of tabular data 2. sub-tab-width positioning The first is of primary importance to me. It is nice to have finer granularity of positioning but it doesn't seem necessary. For editors which remain bound to uniform tabstops, it seems reasonable to implement the primary behaviour, allowing each tab to grow/shrink by units of tab-width rather than single spaces. In that case, I don't see the dependency upon non-uniform tabstops on different lines.

Comments are closed.