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 */ } } }

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

Simple, but brilliant, just brilliant! Well done!

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.

if you have a long condition in your if, will this lead to : if (long_condition) { lalala(); } instead of if (long_condition) { lalala(); }

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

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 */

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+; } }

Great job! The beginning of the end of the Holy War :)

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!

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

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.

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

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.

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.

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.

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(); } }

Jeff Schiller: I know I know. I'm coding a solution as we speak :)

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

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

Frank: You should be okay with the email address as it's not a hyperlink but I'll remove it anyway...

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.

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)

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.

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.

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

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!

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

Is reading monospace fonts really slower than non-monospace fonts? It sounds plausible, do you have any data on it?

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.

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

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?

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.

bobo: Please read my posts below about converting formats. Anyway, what's wrong with trying to improve things?

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.

Utopia is a waste of energy. Is my pessimism showing? Sorry. Go right ahead and ignore me.

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

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

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.

Dave: Thanks Dave - watch this space!

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.

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 ;)

This is not a new idea - I've seen it at least in OneNote 2007 beta. Press TAB - a table is created for you.

alex: Please try the demo...

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

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

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.

Well, in fact that's the same point as Mark Patterson's.

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!

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!

Okay, I've released a new version of the demo. Please have a play and tell me what you think (on the new thread).

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!

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.

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!

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

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?

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.

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.