Slashdot Mirror
Elastic Tabstops — An End to Tabs vs. Spaces?
An anonymous reader writes "Along with Vi versus Emacs, the tabs versus spaces argument must rank as one of the classic holy wars among coders. Here's an attempt to solve it by making tabstops expand or shrink to fit their contents. The concept's pretty cool to use, so be sure to have a play with the demo!"
In command mode, == auto-indents the current line, << and >> indent to right and left respectively.
Back to the original article, I have the following in my
python>>> q="'";s='q="%c";s=%c%s%c;print s%%(q,q,s,q)';print s%(q,q,s,q)
Anyone know of an editor that has this?
If you want that from an IDE, eclipse does that, and pretty robustly at that. I wouldn't want to miss it.
For more simple editors for a quick text edit, my favorite is EditPlus. It lets you choose between classical tabs and whitespace tabs, as how long (in characters) a tab in either mode should be treated, it has the auto-indent you mentioned, reacting to freely definable characters (for example, auto-indent forward after '{' or '(', and back after '}' or ')', respectively). Best of all, it lets you define these parameters independently for plain text, c/c++, java, HTML, Perl, etc., etc., as well as any number of custom syntaxes you may wish to import or define yourself. A small selection of useful features of a great tool. Disclaimer: I am in no way affiliated with Editplus or the company behind it, just a happy user.
The grass is always greener on the other side of the light cone.
So far as I know, "tab" has always meant "Advance the carriage to the next tab stop" and has never meant "advance a fixed number of spaces". The default tab stop setting varies from program to program. In Word its on 1/2" boundaries, and in most editors its on 8-character boundaries.
Intron: the portion of DNA which expresses nothing useful.
I call contradiction!
The Christian Right is Neither (Christian nor right). See: Matthew 23, Matthew 25, Ezekiel 16:48-50
> I think this is the wrong kind of solution to the problem. A standard would be easier.
Clearly you are not familiar with the tabs-vs-spaces argument.
Advocates of tabs say that having everything indended by multiples of some standard
amount is a good thing. This is, of course, wrong for source code in many computer
languages, because it prevents things from being indented to the correct position
relative to the line above, as in the following example (in the Inform language)...
Object matchbox kitchen_cupboard
class cardboard,
with short_name "matchbox",
description "A standard cardboard matchbox.
It says ~Strike on Box~ on the side.",
name 'matchbox' 'box',
has openable container;
I suppose it doesn't matter for write-once applications, but if you're trying
to write _maintainable_ code, it's essential to have things line up properly,
and that means they often need to line up under specific characters on the line
above. That's possible with tabs if the character they need to line up under is
preceded by whitespace (as it generally is with e.g. SQL), but if that's not so,
tabs are useless. I don't see how these new "expanding" tabs change that.
Inform is the *best* example I know of a language that *cannot* be properly
indented with only tabs, i.e., spaces are *needed*. There are other languages
with which this is somewhat true, e.g. Lisp (wherein you often want to line up
under a specific open-parenthesis which may not be preceded by whitespace)
and Perl (although most Perl code is not indented as well as it could be,
partly because tools such as cperl-mode do not support it).
If you agree on a fixed width for tabs (e.g., 8 characters), you could use a
mixture of tabs and spaces, but that won't make tab-indentation advocates happy,
because they want to get *rid* of leading spaces and use tabs only, usually
because they want to use proportional fonts. If you're going to use spaces
for indentation, you might as well use all spaces and no tabs.
Cut that out, or I will ship you to Norilsk in a box.
I don't mind tabs. I don't mind spaces.
But God help you if you mix them together in the same program.
I've met editors that put four spaces for the first indent, then a tab for the second (removing the previous four spaces in the process). It was fine when you viewed the code in that particular editor, but open the same code in another editor with different tab stops, and it became practically unreadable. If they'd stuck with just tabs or just spaces it would have been fine, but nooooo.... some bright spark had to mix 'em together. Grrrrrrr.
(For what it's worth, the editor in question was LSE, on a VMS system. I don't know to this day whether that was the default setting or a setup made by someone at the company, but it caused a nightmare when we ported the system to Windows)
(Spudley Strikes Again!)
You left out verse six:
No animals were harmed in the making of this sig.
Well, there was that one puppy, but he is all better now.
"herefore any indenting in your code should automatically use tab stops and then use spaces to fill in the white space that doesn't lie on a 8-character boundary"
...will always align properly, no matter how width your tab stop is.
Utterly false!
I defy you to find probes of such an abomination!
Any sensible text editor (and to this point almost *all* text editors seem to be sensible enough) won't use spaces on a tab chain *ever*. A tab means "go to the next tab-stop" and only that. So if tab stops are every 8 chars and you are at column #23 a tab won't add a space, but will move you to column #24. If you are at column #25 it won't add 7 spaces, it just will move to column #32. If you change tab length, due to the fact that tabbing DOESN'T ADD SPACES, your editor will do the correct thing (where spaces added, your editor simply wouldn't know what to do, since it can't know it previous spaces were tab-paddind added or hand-added): it'll just go to "the next tab stop", wherever it currently is (and, by the way, that's the whole problem with spaces vs. tabs: the "inner tabbing", because changing the tab width will "jump" some inner tab stops from one point to the previous/next. All-lefty tabs are never a problem, only inner tabs are, and they can be resolved by using lefty tabs and inner spaces).
So...
(tab)function()
(tab)(tab)sentence(tab)//here a comment
(tab)(tab)longsentece(tab)//another comment
will deal to problems.
But...
(tab)function()
(tab)(tab)sentence()//here a comment
(tab)(tab)longsentece()//another comment
[History lesson]
Typewriters - very early typewriters - had tab stops equivalent to 8 spaces. That was it; no ifs, no buts, no negotiation. Later models had the first tab stop equivalent to 8 spaces, then 2 or 3 adjustable tab stops inside that. Even later ones had the first stop adjustable was well.
Y'see, the TAB key is short for "table" - it was designed to make it easy to print tabulated data.
Notice I was very careful to say "equivalent" above - a TAB is not equal to 8 spaces! Nor is it equal to 2, or 4, or 6, or anything else you want to dream up. It's a character in its own right; one whose most common representation is as a gap the same size as 8 spaces.
Somewhere along the line, people involved with computers decided that TAB was actually a macro that meant "print 8 spaces". This was a departure from accepted philosophy and, like most such schisms, led to the Holy War that is still going on. And, like most Holy Wars, people come up with brain-dead attempts at reconciliation that ignore the cause of the problem.
Ever wonder why a config file like
In short: there are 2 whitespace characters in ASCII - the space, being the equivalent of 1 (average) character wide; and the TAB, being nominally 8 characters, but able to be represented (not replaced!) by whatever you want. Don't confuse them.
What part of "a well regulated militia" do you not understand?