While the gedit plugin seems nice, it seems that those accustomed to other editors (e.g., vim) might prefer a more familiar editing environment. How much work has been done on implementations for other editors? Also, would there be any way to arrange for tabulation to be specialized by specific character contexts (e.g., placing tables following an open parenthesis adjacent to the parenthesis, rather than interpolating space between the parenthesis and the following character)? Viz., the difference between foo( bar as seems to be done currently, and foo(bar (where bar is preceded by a tab character and can, in either case, be aligned with further arguments underneath).

David: At the moment I've only worked on implementing elastic tabstops on Java/Swing and GTK. Once I've finished with the gedit GTK implementation (I'm currently working on a faster algorithm), I may have a look at modifying the GTK versions of Vim and Emacs. Which editor in particular are you interested in? I'm not sure I understand your second question - elastic tabstops are language agnostic, just as fixed tabstops are. An editor that uses elastic tabstops may do language specific tab insertion things just as they do today with fixed tabstops.

I'd be interested in a vim version; for random personal use, at least, a Gtk-only version would be fine. The second question was perhaps too specific; more generally, would it be possible to provide some way to align with a character that does not follow visible whitespace? The motivation is that, when aligning a block of text following an operator (in the most general sense, including as operator '(' as well as '+', '-', etc.), certain of these (such as the parenthesis) are not normally separated from their next argument by a space. While the relevance of this point might be most apparent in a context such as Lisp programming, it may also affect more common languages. In C, for example, the function call foo(bar[1], bar[2], .... might, for a sufficiently large set of arguments, be displayed (for at least some coding styles) with some bar[n] aligned with bar[1]. In the current gedit plugin, this result can be visibly approximated by setting paddingwidth to 1 (zero doesn't seem to work), and using non-tab whitespace to establish custom padding values as desired; it is unclear that this particular approach to the problem is optimal, however.

David: To make it line up you need the tab on the first line line to start the column block. The code would look like this: foo( bar[1], bar[2], ... You should never need to use spaces to line things up. Visibly speaking you can remove the gap between "foo(" and "bar[1],", by changing the amount of padding between columns (although there may be a bug if you use a value of 0 - I'll have to check).

Would it be possible to adjust the amount of padding depending on character context, so that characters such as parentheses would not be automatically padded against their contents?

David: Interesting idea... I have a couple of concerns though. For one thing it will make the algorithm more complicated, and secondly it may make it more difficult for people to understand the underlying concept. Since the concept is new and a little controversial, and some people seem to have problems getting to grips with the idea, perhaps we should at least wait until elastic tabstops become more widely used. I think what you're suggesting is a way to make the visual appearance of the code look as close as possible to an existing code style (no gap after the round bracket). While I can see that this may be desirable, since the actual text will be different (in this case with a tab character after the opening round bracket), is there any point in trying to hide this fact?

Yes, I think there is a big reason to hide it: aesthetics! It looks ugly otherwise (to people that don't use space after parens). If people can't replicate the styles they like, they won't use elastic tabstops. Moreover, it's not a global on/off decision. Most people will want 0 padding after parens:: (foo bar baz) but will want padding after bullets: * Foo bar baz... I think therefore that the margin should be always 0, and when people want a margin they should put a space as well as a tab ("."=space, "|"=tab): (|foo bar |baz) *.|Foo bar |baz... Also, I think we should introduce Elastic spaces (TM): when using proportional font, leading spaces (and perhaps sequences of more then 2 spaces in the middle) should simulate fixed font by aligning with corresponding characters on the line above. True, this is sub-optimal because you must adjust the number of spaces as you edit the text. But it's great for backward compatibility - existing space-aligned texts will look much better under proportional fonts.

On a second thought, you have a good point. If there is a tab there and the editor doesn't show it, it could cause a problem. Specifically, a tab between two alpha-numeric characters must not have 0 width. And in some languages such as lisp of forth almost any whitespace is meaningful! Therefore, 0-width tab display can only be allowed in editors that show the tab as a vertical line. Also, my previous suggestion that a space must be added manually where desired would cause people to type many space+tab combinations, which is an annoying waste of their time. I take it back :-)

Hello! Greate plugin, but can You provide valid configure.ac and other files to build whis plugin for amd64 arch?

I came across this "elastic tabstops" while looking for an editor that provides "old school" tabs--that is to say, just like a typewriter works. I remember using a MS-DOS program called PC-Write (before the days of WYSIWYG) that had embeddable tabstop lines to control where the tab char would go. Your solution is a dynamic, self-minimizing version of that. And it's not just for software! In fact, I find it MUCH MORE important when dealing with tab-separated-values data files. Until this, the only solutions were "ts=VeryBigNum" (lots wasted space) or loading the file into Excel (yuck!). Great work!