Elastic tabstops - a better way to indent and align code

Post about first public version of elastic tabstops

Okay, it's been suggested I create a way to keep people informed, so here it is.

Posted on Friday, 2006-07-07 at 02:58 UTC

58 comments


Wednesday 2006-07-05 00:22 UTC
Mark Patterson <mark DOT aurelius AT gmail DOT com>
It didn't seem to work if a comment rectangle needed to span multiple levels of indentation, and tabs were being used for indentation. Maybe this is asking too much, and spaces should be used for indentation: #include int main(void) { x(); /* try making */ printf("hello!\n"); /* this comment */ doSomethingComplicated(); /* a bit longer */ if (1) { lalala(); /* This is a comment on lalala */ if (nothing.happens()) { /* this is a nothing comment */ something.do(); /* This line show that this is broken too */ } } }

Wednesday 2006-07-05 00:46 UTC
Nick
You can improve that by adding some extra tabs: #include int main(void) { x(); /* try making */ printf("hello!\n"); /* this comment */ doSomethingComplicated(); /* a bit longer */ if (1) { lalala(); /* This is a comment on lalala */ if (nothing.happens()) { /* this is a nothing comment */ something.do(); /* This line show that this is broken too */ } } } I have a plan that will fix the line with something.do being too far to the right, and I'll announce that soon...

Wednesday 2006-07-05 01:35 UTC
RonKinOz
Simple, but brilliant, just brilliant! Well done!

Wednesday 2006-07-05 02:10 UTC
Eric
What seems like the most useful feature of this is the fact that you can't use tabs to line up things within a column, you're forced to use spaces. e.g. line continuations need to be lined up with spaces: printf("hello! %s\n", "more text"); /* this comment */ ^^^^^^^ spaces ^ tab I've been using this style for years and it works reasonably well in most editors. (at least until you try to do a > in vi to shift things over) The elastic tab idea is great for lining up things that are farther to the right though.

Wednesday 2006-07-05 03:33 UTC
jean
if you have a long condition in your if, will this lead to : if (long_condition) { lalala(); } instead of if (long_condition) { lalala(); }

Wednesday 2006-07-05 07:21 UTC
Nick
Jean: you must have a tab on the end of your if line. Remove that and it wil indent properly. BTW I have a modification in mind that will ensure that indentation (first tabs on line) does not change width. This is peoples biggest complaint, so I'm eager to get it fixed. PS. I've hacked the comment system here so that you can paste example text from the demo editor straight into a comment, and after the comments posted it can be copied straight from the page back into the demo editor...

Wednesday 2006-07-05 10:29 UTC
Nick
Eric: That coding style is only possible using spaces and a monospaced font. How about this: printf( "hello! %s\n", "more text"); /* this comment */ or if you must have the first argument on the same line as the function call, this: printf( "hello! %s\n", "more text"); /* this comment */

Wednesday 2006-07-05 12:00 UTC
Teddy
I don't understand the example. int main(void) { x(); /* try making */ Why doesn't the x() line out after int main(void)? Also this style forces you to place blank lines in between your code. If you don't you get weird results: doSomethingComplicated(); /* a bit longer then usual */ for (int i= 0; i<50; i++) { if (i == 2) { tadaa+; } }

Wednesday 2006-07-05 12:25 UTC
Alex
Great job! The beginning of the end of the Holy War :)

Wednesday 2006-07-05 12:57 UTC
Nick
Teddy: I'm not sure what you mean by "Why doesn't the x() line out after int main(void)?" - could you elaborate? I have a modification I plan to make soon which will solve the issue with having to put blank lines everywhere - stay tuned!

Wednesday 2006-07-05 13:04 UTC
Nick
Teddy: I understand what you're getting at now. Basically beacuse there is no tab character after "int main(void)" there's nothing to push the tabstop along. Hope that makes sense...

Wednesday 2006-07-05 14:08 UTC
Steve Valliere
At the risk of roasting in effigy... I think this is very good, but it /might/ be even better if it supported a couple extra, tab-related things: 1: An option to align ALL trailing comments. This is an option in some editors and the indent utility. 2. Right and decimal aligned option for some tabs, would also be nice, at times. This is a kinda 'pie-in-th-sky' wish, but I think its possible, given what already exists.

Wednesday 2006-07-05 14:33 UTC
Nick
Steve Valliere: > 1: An option to align ALL trailing comments. This is an option in some editors and the indent utility. That's not really my concern at the moment - it's the job of the people who write the editors that use elastic tabstops to add this feature. I imagine it should be pretty trivial though... > 2. Right and decimal aligned option for some tabs, would also be nice, at times. This is a kinda 'pie-in-th-sky' wish, but I think its possible, given what already exists. I suppose it would be possible for the system to change the alignment of a cell if it can parse its contents as a number. I'm not sure we want to go this far though. Right now, I'm concentrating on getting the optimum alignment for code so that I can get people to coopt the idea...

Wednesday 2006-07-05 15:19 UTC
johnny bravo
The biggest issue is that there is no way to keep some moron from just typing 4 spaces to try and indent something. This case is ignored by the article. There are two sides to this issue: 1) What do you do when someone types a tab character? 2) What do you do if someone uses spaces to manually indent something? Should it be converted to a tab? How can the user detect it if the result looks the same in a monospaced editor? The article only covers one of these scenarios. A true solution would be bilateral. The solution provided by the article is broken if someone decides to manually indent something with spaces and can't tell the difference by the appearance of the text.

Wednesday 2006-07-05 15:30 UTC
JST <tomlinjim AT hotmail DOT com>
I started worrying about tabs vs. spaces for source code 25 years ago. I settled on a simple rule: store no tab characters in file -- only spaces, pressing the tab KEY inserts spaces (though I have waffled from 2 to 3 to (now) 4 spaces per tab-stop.) The great benefit of spaces-only is that i never never never ever suffer the shock and weirdness of seeing my code suddenly displayed with wrong tab stoppage. The small price is that I have to press the delete/backspace keys a little more often. Sure, my source files are a smidge bigger than they might be with tabs, but source file size has never been a problem, even in the days of 180K floppies. That said, I think it is great that somebody is looking forward to a future where code is formatted according to its meaning. Please keep working on it. But for now I'll stick with plain text, spaces, and a monospaced display.

Wednesday 2006-07-05 15:55 UTC
Nick
johnny bravo: > The biggest issue is that there is no way to keep some moron from just typing 4 spaces to try and indent something. This case is ignored by the article. That's because at the moment I'm only concentrating on getting the elastic tabstop control working. It's the text editor application's job to go through and replace spaces with tabs etc. That said I have thought about it and have a system which will hopefully deal with it when I start making a proper editor that uses the finished elastic tabstops control.

Wednesday 2006-07-05 18:44 UTC
Jeff Schiller <jeff_schiller AT hotmail DOT com>
As others have pointed out, the biggest flaw I could see is that blank lines are required in many places to get code at the same indenting level to be aligned. Take this simple example: int main(void) // <-- putting a tab after main pushes out subsequent code for no reason { x(); /* try making */ printf("hello!\n"); /* this comment */ doSomethingComplicated(); /* a bit longer */ // now subsequent code is not aligned with the above if (1) { lalala(); } }

Wednesday 2006-07-05 18:59 UTC
Nick
Jeff Schiller: I know I know. I'm coding a solution as we speak :)

Thursday 2006-07-06 02:34 UTC
Frank
If we want to continue using this old-fashioned stuff called 'text' for our source code, the Elastic Tabs idea is great. But I think using text is a pretty bad idea. I'm not the only one. Take a look at the Source Code In Database idea, at . It's been around for a long time. I wish tools would start going down that route. Cheers, --jsf

Thursday 2006-07-06 02:36 UTC
Frank
Hyperlink disappeared, here's the SCID address again: <a href="http://mindprod.com/projects/scid.html">SCID</a> ** Hey, Nick, can you remove my email address from the last post. You really shouldn't put those things up on the web, now i'll be getting lots of spam. Thanks, --jsf

Thursday 2006-07-06 07:43 UTC
Nick
Frank: You should be okay with the email address as it's not a hyperlink but I'll remove it anyway...

Thursday 2006-07-06 12:04 UTC
Chris Jones
The main problem with using tabs to align code is that they're interpreted differently with different tab stop settings. What you're proposing here is yet another way to interpret tabs. Surely this makes the problem worse? Your system would work great if everyone used it but that's not going to happen. So the fact that you can't share code between people using old style tabs and your funky tabs means that there's just no way it can take off. I do like this system and it's a good way for an editor to work internally. But the current mess means that any system which involves actually storing tabs in source code is no good.

Thursday 2006-07-06 12:17 UTC
Nick
Chris Jones: Well, at the moment someone's working on a mode file for Emacs, I have "Proportional Vi" on the go, and the demo system can be added to any Java editor that uses standard Swing components, so I think we can cover a lot of bases when it comes to having editors that support this. On your second point, I think it should be pretty trivial to make an editor that converts spaces to tabs on loading a file and strips out any redundant spaces on saving (and/or converts all tabs back to spaces)

Thursday 2006-07-06 16:29 UTC
Chris
Ok. I didn't phrase that right. There are two problems with current methods of indentation. 1) It doesn't work very well. Especially in the case where you want to line up two columns and the variation in the left column is greater than the size of a tab. Elastic tabs solve this. 2) Not everyone has their tab stops set to the same thing. So code which looks beautifully aligned on my machine looks terrible on yours. By the time a third person has come along and edited the same file using spaces for the indent, it looks even worse. This is the problem that elastic tabs exacerbate. The fact that elastic tabs may be supported as an option in emacs doesn't help at all. It's all about which option people decide to turn on. I can't leave emacs in elastic mode by default because old code (and new code that I write for old projects) will look wrong. Given that I, and everyone else who's likely to read my code, will be using old tabs by default. I just can't see myself using elastic tabs, however much better they are. The only ways I can see round this is some sort of backwards compatibility mode, to make sure that files created with elastic tabs look readable in old tabs mode. For instance, if a cell gets expanded because of a long line, the other lines get padded with spaces when you save the file (maybe you have to put the spaces before the tab rather than after so that it will be easier to recognise them as padding spaces when you come to load the file back in (tab-space is a common thing to do but space-tab is less so)). I realise that this is a bit of a kludge, maybe there's a better way. It needs something though. The alternative is that even the most ardent fan of elastic tabs can only use them on personal hobby projects.

Thursday 2006-07-06 17:30 UTC
Nick
Chris: > The only ways I can see round this is some sort of backwards compatibility mode, to make sure that files created with elastic tabs look readable in old tabs mode. For instance, if a cell gets expanded because of a long line, the other lines get padded with spaces when you save the file (maybe you have to put the spaces before the tab rather than after so that it will be easier to recognise them as padding spaces when you come to load the file back in (tab-space is a common thing to do but space-tab is less so)). I should have given a bit more detail in my last post. Once I have the elastic tabstop reference implementation sorted out I'll probably go on to make a reference editor that uses it. As well as saving tabs as is, it will also offer the option to be able to load/save files using the mod-N spaces/tabs indentation systems. The user will supply the editor with the tab size (N) used by their coding standard, and then... * On loading the file, the editor will figure out what text has been aligned together by comparing character positions and strip spaces and tabs as necessary * On saving the file, the editor will treat the file as a 2D character grid (just like in a traditional monospaced editor) and insert spaces/tabs accordingly There will be problems when it's given badly aligned files, but that's the users fault for not knowing how to indent (and they'd look bad in a character mapped editor too anyway)... Also, even when given a perfectly space aligned file there may be differences between the original file and the new file... All in all though it should work okay I think.

Thursday 2006-07-06 18:55 UTC
Mind Booster Noori <marcos DOT marado AT sonae DOT com>
The intention is good, but elastic tabstops is utterly flawed, at least for now, and shouldn't be considered. Not only everyone that edits that file has to have an editor with an elastic tabstops implementation, but opening old files (with the spaces or tabs choice of today) would create a real mess. And if the chalange today is getting everyone choose from "tabs or spaces", what about when they have to choose from "tabs, spaces or elastic tabspaces"? Fear...

Thursday 2006-07-06 19:21 UTC
Nick
Mind Booster Noori: Hang on there, once I get round to writing a proper editor that uses the elastic tabstops text component you'll see that it is possible to coexist with other coding standards. The idea of using tab as a delimiter will actually make converting to the other standards much easier!

Thursday 2006-07-06 19:46 UTC
Scott <ssnoyes AT hotmail DOT com>
You argue that we currently indent code for aesthetics and not semantics. Elastic tabs do the same (but better). I'll be watching for the vi implementation...

Thursday 2006-07-06 20:13 UTC
anonymous
Is reading monospace fonts really slower than non-monospace fonts? It sounds plausible, do you have any data on it?

Thursday 2006-07-06 20:15 UTC
Jim E-H
To heck with other people; I'd be happy just to have my code look the same in Eclipse and Emacs! I'll be eagerly awaiting implementations for those two. The one other thing I'd like to see (which I understand is an editor feature, not a feature of elastic tabstops) is to preserve the original whitespace in unchanged lines when saving a file. That is, I'd rather not have an editor that converts the whole file and saves the converted version, because I end up with huge meaningless diffs in CVS.

Thursday 2006-07-06 21:06 UTC
Nick
anonymous: I have seen reports before but I don't have any links to hand and I'm too busy right now to search for it. There are sites that talk about typography so they might be a good place to look...

Thursday 2006-07-06 21:11 UTC
Nick
Jim E-H: When I make any editors there will be options to save "as is" as well as converting to the mod-N spaces/tabs indentation formats. BTW, can't you use the -w option in diff to ignore whitespace?

Thursday 2006-07-06 21:12 UTC
bobo
What is the purpose of this blog? Do you really think the world will comply and change the way it does tabs? Why not just make your own text editor or find one that does what you want rather than propose changing tabs. I would not want to change all the code I have written to display the way you propose. It would be a nightmare.

Thursday 2006-07-06 21:15 UTC
Nick
bobo: Please read my posts below about converting formats. Anyway, what's wrong with trying to improve things?

Thursday 2006-07-06 22:24 UTC
Chris <mail AT cjones DOT org DOT uk>
Thanks for the quick answers and sorry if I sounded negative earlier Nick. I can't wait to have a play with proportional vi. And the end result (the glorious day when all editors work like this) will be a vast improvement.

Thursday 2006-07-06 22:31 UTC
bobo
Utopia is a waste of energy. Is my pessimism showing? Sorry. Go right ahead and ignore me.

Thursday 2006-07-06 22:41 UTC
Nick
Chris: Cheers mate! I totally understand people criticising it, and a lot of it helps me understand other coder POV, which can only help. My favourite comment so far was on slashdot: "He implies that this is a middle-ground solution, however, this "solution" is of the opinion that tabs are what are intended for formatting. So it's really not a compromise at all, but an evil Tabbist plot! (j/k) ^^" :D

Thursday 2006-07-06 22:52 UTC
Nick
bobo: No worries! I use tabs in all of my projects (spaces just seems like the lowest common denominator to me), so if my idea takes off I'll have to worry about existing code too...

Friday 2006-07-07 02:33 UTC
Dave
This looks interesting. The problem first noted by Mark Peterson is a major hurdle along with requiring blank lines be placed to adjust tab positions. If these are solved this is something I would use.

Friday 2006-07-07 02:56 UTC
Nick
Dave: Thanks Dave - watch this space!

Friday 2006-07-07 03:37 UTC
Marc Siegel
Maybe you should start a project on SourceForge and reserve the domain www.elastictabs.org. This could serve as a central place for people to post their experiences converting editors, adn then work places, to this system. I really like it! I hope you consider making right-aligned numbers an option.

Friday 2006-07-07 09:12 UTC
Nick:
Marc Siegel: Thanks, I'll think about it... BTW, it's "elastic tabstops", not "elastic tabs" - tab characters on their own don't really do much ;)

Friday 2006-07-07 18:40 UTC
alex <nospam AT mail DOT com>
This is not a new idea - I've seen it at least in OneNote 2007 beta. Press TAB - a table is created for you.

Friday 2006-07-07 18:49 UTC
Nick
alex: Please try the demo...

Friday 2006-07-07 20:42 UTC
Jim E-H
"BTW, can't you use the -w option in diff to ignore whitespace?" Yeah, I can (and do) on the command line, but not all environments that interface with version control are that flexible. But I wanted to get the idea out there that an editor that makes major changes to files for its convenience is a bad thing, and only really works well if a. everyone is using it so it's a one-way conversion or b. it's the only editor that does that. Neither seems like a condition that should be assumed.

Friday 2006-07-07 20:52 UTC
Nick
Jim E-H: Yeah, I know what you're saying but some of this stuff gets quite difficult. Let's cross this bridge when we get there. I have a few ideas...

Sunday 2006-07-09 00:41 UTC
Ukuk
I guess lines with { and } should be handled just like blank lines. Check this: if ( 1 && asdfjalçksdfj() && fdsa() ) { while(1) { IMNotConvinced(); } lalala(); /* asdfasdf */ SomeVeeeeeeeeryLongFunction(); /* asdfasdf */ } Or, ad you wrote, consider semantics. Some tabs are used for lining up comments, others for conditions, and yet others for code blocks.

Sunday 2006-07-09 17:00 UTC
Ukuk
Well, in fact that's the same point as Mark Patterson's.

Sunday 2006-07-09 20:20 UTC
Nick
Ukuk: Actually, there's a much better solution which I have working now and will release tomorrow. Oh yeah, I want this to be as simple a solution as possible, so I won't be doing anything language specific. Tomorrow's release should demonstrate that it's not necessary!

Monday 2006-07-10 06:36 UTC
Dave
Nick: Oh yeah, I want this to be as simple a solution as possible, so I won't be doing anything language specific. Tomorrow's release should demonstrate that it's not necessary! I would have thought that this would only work whith some knowledge of the language being edited such as block delimiters. If that is not the case I will be interested to see your release tomorrow. Great work!

Monday 2006-07-10 13:43 UTC
Nick
Okay, I've released a new version of the demo. Please have a play and tell me what you think (on the new thread).

Wednesday 2006-07-12 22:36 UTC
Gene Wirchenko <genew AT ucantrade DOT com>
I agree with JST's comment. I use spaces. On a related note, with proportional fonts, tabs do not mean what they used to. It is possible to mess up the arrangement of a document by changing the font/size. I think that the tab should register regardless of whether one already past the point of the tab. Just make it a no-op. Currently, with a short piece, you might need to tab twice, and with a larger font, you only need tab once. BOOM!

Wednesday 2006-07-12 23:47 UTC
Nick
Gene Wirchenko: > On a related note, with proportional fonts, tabs do not mean what they used to. It is possible to mess up the arrangement of a document by changing the font/size. > I think that the tab should register regardless of whether one already past the point of the tab. Just make it a no-op. Currently, with a short piece, you might need to tab twice, and with a larger font, you only need tab once. BOOM! Umm, this is what elastic tabstops fixes. Please look at the demo and read the explanation. You can change the font and size of indentation to whatever you like and everything will always line up.

Friday 2006-07-14 00:45 UTC
Frank
Can I take this tabs vs spaces argument back to basics and ask the question, why should anyone have to follow anybody elses standards. I should be able to code in the style that I want. HTML markup can be styled anyway you want with an appropriate stylesheet. In this day and age, I can't believe no one has come up with an IDE that allows me to apply a stylesheet to my code so that it shows tabs, or spaces or whatever the hell I like when coding. Sheesh!

Friday 2006-07-14 11:54 UTC
Nick
Frank: Eclipse can reformat code according to your coding style, and I'm sure there must be other editors that do that too. Please note that while the elastic tabstops idea does not change the contents of a file (it just changes the way a file is displayed) there's nothing to stop an editor that uses the elastic tabstops system from reformating code like Eclipse...

Wednesday 2007-01-03 17:02 UTC
Will
Excellent idea, it will be interesting to see it develop. I am currently thinking about editors that use lexical & syntax information in C-like languages to set tab-stops for each line. For example, the editor would know the difference between a function declaration, a function call, an arithmetic expression etc... and would set the tab-stops as appropriate. Any comments?

Wednesday 2009-02-25 09:44 UTC
Witek <w AT w DOT pl>
There is small problem: if (1) {// this comment x(); } Mayby separate into two classes 's which starts from empty line, and one which didn't.

Wednesday 2009-02-25 09:45 UTC
witek <w AT w DOT pl>
There is small problem: if (1) {TAB// this comment TABx(); } Mayby separate into two classes TAB's which starts from empty line, and one which didn't.

Comments are closed.