Elastic tab stops
Mar. 24th, 2011 02:41 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
jackhttp://nickgravgaard.com/elastictabstops/
I remember a year or two ago hearing about elastic tab stops, and how at first it immediately seemed right a fulfilment of what tabstops are supposed to be, and implemented or not, useful for resolving the tabs-v-othertabs-v-spaces holy war conceptually if not in fact. But then later, it seemed an uphill struggle to implement it in real life, if you expect it to interoperate with other code editors.
At the time, I assumed the implementation would need to store the code in an other-editor-unfriendly and diff-unfriendly fashion, either (i) using a single tab character to indicate when an elastic tab stop was due or (ii) using some meta-data (smuggled in comments, or whatever) to indicate where the tabstops should be.
However, now, I can't remember why I assumed that? Surely if the editor maintained the existing whitespace as spaces or tabs, but looked for pieces of code like:
After all, when was the last time when you deleted/inserted a character exactly on a tab stop, or followed by multiple spaces, and DID want the rest of the line to move? Surely if it's followed by a tab or multiple spaces, then 99.999% of the time, the rest of the line is designed to line up with something else, not to be a very specific distance from the part of the line you're editing? So simply "not screwing that up" would fix an awful lot of stuff, without any knowledge of syntax or whatever at all?
Admittedly, if you do have a line where you want a very specific number of spaces between two things, it wouldn't work, but when DO you ever want that? 0 and 1 spaces are very common, 2 very occasionally for indicating multiple levels of operator precedence, but 2+ spaces or a tab almost always mean "decouple the x-coord of this bit from the x-coord of the next bit?"
If many editors did that, it would be comparatively simple to EXPAND that functionality in lots of obvious ways, but it's generally a lot easier to get a new paradigm adopted by making it easier to adopt, than by making it MORE better.
What am I missing?
I remember a year or two ago hearing about elastic tab stops, and how at first it immediately seemed right a fulfilment of what tabstops are supposed to be, and implemented or not, useful for resolving the tabs-v-othertabs-v-spaces holy war conceptually if not in fact. But then later, it seemed an uphill struggle to implement it in real life, if you expect it to interoperate with other code editors.
At the time, I assumed the implementation would need to store the code in an other-editor-unfriendly and diff-unfriendly fashion, either (i) using a single tab character to indicate when an elastic tab stop was due or (ii) using some meta-data (smuggled in comments, or whatever) to indicate where the tabstops should be.
However, now, I can't remember why I assumed that? Surely if the editor maintained the existing whitespace as spaces or tabs, but looked for pieces of code like:
and resized them dynamically whenever you edited the whitespace, wouldn't that be right nearly all of the time? And it works better if everyone has smart editors, but it works ok when only some do.func(alpha, 1); func(beta, 2); func(gamma, 3); blah(); // comment blah_blah(); // comment moreblah(); // comment
After all, when was the last time when you deleted/inserted a character exactly on a tab stop, or followed by multiple spaces, and DID want the rest of the line to move? Surely if it's followed by a tab or multiple spaces, then 99.999% of the time, the rest of the line is designed to line up with something else, not to be a very specific distance from the part of the line you're editing? So simply "not screwing that up" would fix an awful lot of stuff, without any knowledge of syntax or whatever at all?
Admittedly, if you do have a line where you want a very specific number of spaces between two things, it wouldn't work, but when DO you ever want that? 0 and 1 spaces are very common, 2 very occasionally for indicating multiple levels of operator precedence, but 2+ spaces or a tab almost always mean "decouple the x-coord of this bit from the x-coord of the next bit?"
If many editors did that, it would be comparatively simple to EXPAND that functionality in lots of obvious ways, but it's generally a lot easier to get a new paradigm adopted by making it easier to adopt, than by making it MORE better.
What am I missing?