Elastic Tabstops — An End to Tabs vs. Spaces? 263
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!"
From Wiki (Score:5, Funny)
My bible says it is morally wrong to use Vi.
Re:From Wiki (Score:3, Insightful)
Re:From Wiki (Score:3, Funny)
Well, of course it is. VI is Latin for 6, which is 1/3 of 666, and we know what that stands for.
As further proof, check vi's origins. It came from Berkeley, and their BSD system has a little d[a]emon as a symbol. Spawn of Satan, QED.
Re:From Wiki (Score:5, Funny)
Mine says,
"And behold sayeth the Lord, thou shalt edit thine text in Vi and Vi alone, even when thou art forced by the unclean luser to useth the operating system of unholiness. Thou shalt always keep a copy of the Holy editor on thine key of the USB lest thou shalt fall into temptation and edit thine text in the way of the unclean. Any who useth Emacs or the accursed notepad shalt be stricken from the Book of the Holy Sysadmin for all eternity. So sayeth the Lord." -1st Epistle to the Admins of Systems 1:15-16
There it is in black and white. Vi is the way of truth and light. All others are unclean.
Re:From Wiki (Score:3, Insightful)
Re:From Wiki (Score:3, Interesting)
Re:From Wiki (Score:3, Informative)
Re:From Wiki (Score:2, Informative)
You left out verse six:
Re:From Wiki (Score:2)
Re:From Wiki (Score:2)
Fi on vi! Emacs forever!
Re:From Wiki (Score:2)
Re:From Wiki (Score:2)
How we got here (Score:5, Interesting)
The way we got into this mess is that in early versions of UNIX, tab stops were set to 8 spaces in the TTY handler. This was not because tab stops were intended as indentation. It was because an ASR-33 teletype could tab that far in one character time. It was for optimizing output time. (Back in those days, TTY output processing had to have time delays to handle the mechanical lag in printers. "How many nulls were required after each carriage return" was an issue, and better systems kept track of the printing column position and adjusted the delay accordingly. Peripherals used to be really dumb.)
If some reasonable indentation value like 4 or 5 had been chosen, everything would have been fine.
Re:How we got here (Score:3, Interesting)
Not just mechanical output devices. I wrote a TTY driver for a Viewpoint terminal that I was driving from an 8052. That thing needed delays all over the place. (Imagine my surprise, years later, to open one up and find an 8051 sitting in there.) I actually discovered it needed delays from the UNIX side of things, because the first thing I implemented was a serial-to-serial pass through, and I had to mess w/ the various stty delay settings before I stopped losing text.
But, yes... 80 columns goes back
whether or not this solves the problem (Score:4, Insightful)
Whether or not this solves the problem (I don't think it does), I get real nervous when source code starts being perceived as a document that lends itself to proportional fonts. Maybe I haven't been in the latest and greatest IDEs lately and am missing something here, but source code seems to scream for canonical form, and proportional font is not that.
I think vim has a reasonable approach (do the research: shiftwidth, tabstops, softtabstop, etc.), I assume there are other approaches in emacs.
Start talking about proportional font source code documents, and now everyone's going to want to have styles, and all the confusing garbage that is word processing. As difficult as source code and programming is, it doesn't need to be more nuanced in word processing.
Re:whether or not this solves the problem (Score:2)
Not that I'm for it
Re:whether or not this solves the problem (Score:3, Interesting)
I use the command line program ident to apply my style to other people's code, sure I don't send them this way I r
Re:whether or not this solves the problem (Score:3, Interesting)
Yeah, but people would still screw it up. For example:
if () {
} else {
}
if ()
{
}
else
{
}
# Conway style
if () {
}
# This also is a problem with BSD, but I thought I
A Tab is one character that represents 8 spaces. (Score:2)
Re:A Tab is one character that represents 8 spaces (Score:2)
Re:A Tab is one character that represents 8 spaces (Score:2)
Re:A Tab is one character that represents 8 spaces (Score:2)
The computer industry is a bit weird in its use of fixed-width fonts, which publishers usually find unaesthetic, but which are very useful to us computer geeks. But we do have word processor software that also default to variable-width fonts and indent by distance rather than chars. And CSS let
Re:A Tab is one character that represents 8 spaces (Score:2)
Well, that's a broken idea (Score:2)
With the line:
And watch as the tab spacing of "lalala();" two lines down gets ruined.
He's right that mandating "tabs must be N spaces" is stupid, though. Use tabs to indent blocks of code, use spaces for aligning code that isn't in blocks, and people should be able to set whatever tab size they want without ruining anything.
Oh... Honestly! (Score:2)
Then emacs will replace tabs with spaces. In the various programming language modes, tab indents to the right location (Which you can customize somewhere else.)
vim has a similar setting but I rather despise vim (I prefer nvi or old school vi when doing vi things.)
Brilliant! (Score:2)
Not really a compromise. (Score:2)
Hoped by whom?
However, this type of formatting has been around for a while, in better language-sensitive editors, where you can adjust for formatting for the various coding contexts.
A b
The subject of tabs vs spaces should be clear (Score:4, Insightful)
Let me quote the relevant standard:
Linux kernel coding style
[cut]
First off, I'd suggest printing out a copy of the GNU coding standards,
and NOT read it. Burn them, it's a great symbolic gesture.
[cut]
Chapter 1: Indentation
Tabs are 8 characters, and thus indentations are also 8 characters.
There are heretic movements that try to make indentations 4 (or even 2!)
characters deep, and that is akin to trying to define the value of PI to
be 3.
Rationale: The whole idea behind indentation is to clearly define where
a block of control starts and ends. Especially when you've been looking
at your screen for 20 straight hours, you'll find it a lot easier to see
how the indentation works if you have large indentations.
Now, some people will claim that having 8-character indentations makes
the code move too far to the right, and makes it hard to read on a
80-character terminal screen. The answer to that is that if you need
more than 3 levels of indentation, you're screwed anyway, and should fix
your program.
In short, 8-char indents make things easier to read, and have the added
benefit of warning you when you're nesting your functions too deep.
Heed that warning.
[cut]
But even if you fail in getting emacs to do sane formatting, not
everything is lost: use "indent".
Now, again, GNU indent has the same brain dead settings that GNU emacs
has, which is why you need to give it a few command line options.
However, that's not too bad, because even the makers of GNU indent
recognize the authority of K&R (the GNU people aren't evil, they are
just severely misguided in this matter), so you just give indent the
options "-kr -i8" (stands for "K&R, 8 character indents").
"indent" has a lot of options, and especially when it comes to comment
re-formatting you may want to take a look at the manual page. But
remember: "indent" is not a fix for bad programming.
Linus Torvalds.
Consistency is better than religion (Score:4, Insightful)
For several large projects I work with where there are lots of developers, consistency of the source code is considerably more important than any particular developer's opinion on what the correct behavior of tabs and spaces are. These are projects where it is pretty much expected that there are or will at least eventually be developers that use both vi and emacs with zealotry as well a myriad of IDE environments. For at least vi and emacs, all source files utilize a local variables block that is understood by both editors in order to encourage a project-defined convention with consistent indentation:
With that comment block at the very end of all source files (whether they be C, C++, Tcl, Perl, Sh, SGML, etc), we do quite well in maintaining order and minimizing the indentation dispute. For the IDE environments, it at least gives them clear documentation on how to configure their IDE indentation preferences to match in every file. Maintaining a tabwidth/tabstop of 8 ensures consistent source display in most environments, including text printing and console display, leaving projects to simply define what offset/shiftwidth level they want for indentation. It can similarly still be tweaked for the projects that seem to insist on no tabs or want to match some IDE default religion.
Don't mix em. (Score:3, Informative)
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)
Great, now we have a THIRD standard to fight over (Score:2)
But if you thought we had holy wars now, just imagine the nightmare that a third option will introduce...
There is no doubt about what is the right thing. (Score:2)
Why should everybody degrad
Uh... ok... (Score:4, Funny)
Tabs just need to go away so we can get back to real debates, like CR vs. CR/LF vs. LF.
build in indent (Score:2)
Then, who cares how things really are, we have our preference automatically assured!
This could perhaps be extended to changing between different spellings, I.e. Americanish => English.
Re:A standard tab length would be easier (Score:2)
both vim and emacs will do this. unless i misread the question...
Re:A standard tab length would be easier (Score:2)
I want to be able to indent or unindent the opening statement for a given loop, be it int, sub, function, if, for or else, and have the entire section that it describes, including the braces, indent accordingly. Anyone know of an editor that has this?
both vim and emacs will do this. unless i misread the question...
I think maybe he's asking for something that moves a whole block of text like (emacs example) Ctrl-Space at beginning, cursor to end, Ctrl-X-Tab... but does so without having to cursor all t
Re:A standard tab length would be easier (Score:2)
I think maybe he's asking for something that moves a whole block of t
Re:A standard tab length would be easier (Score:2)
Emacs can do all that. The only drawback is that you have to use Emacs :) ccmode and a abbrmode, I think.
Re:A standard tab length would be easier (Score:2)
I don't know what the big deal is, just
Re:A standard tab length would be easier (Score:2)
Re:A standard tab length would be easier (Score:4, Insightful)
Re:A standard tab length would be easier (Score:2)
Re:A standard tab length would be easier (Score:5, Funny)
Re:A standard tab length would be easier (Score:2)
Re:A standard tab length would be easier (Score:2)
My coding style is that a single function can go several levels/indents deep, too wide a tab space can really start eating up screen space.
Re:A standard tab length would be easier (Score:2)
If a chunk of code is to be used in various places, then you have othe
Re:A standard tab length would be easier (Score:5, Insightful)
You might as well tell the world "Earth's official language is now officially Esperanto, so fuck you". The effect would be about the same.
Re:A standard tab length would be easier (Score:2)
You might as well tell the world "Earth's official language is now officially Esperanto, so fuck you". The effect would be about the same.
La lingvo oficiala da tero estas Esperanton, tial fiku vin!
Re:A standard tab length would be easier (Score:3, Insightful)
Mi pensas, cxu "fikugxi" ne estas pli tawga vorto? :P
Saluton, karaj esperantistoj!Re:A standard tab length would be easier (Score:2)
Mi pensas, cxu "fikugxi" ne estas pli tawga vorto? :P
Jes, sed "fikugxu"? Mi ne scias. Posible "fikugxegacxu"? :-)
That last one makes me want to say "Gesundheit" (try saying it out loud).
Re:A standard tab length would be easier (Score:2)
Re:A standard tab length would be easier (Score:3, Insightful)
They became interwoven into the computer-programming subset of society back in the 60's and 70's, if not earlier.
But even beside that, a lot of things are set semi-arbitrarily in the tech world. So why not the length of a tab?
Because the proposal isn't to define a new standard, it's to re-define a very well-entrenched (if crappy) existing standard. All 60 million people who are alrea
Re:A standard tab length would be easier (Score:3, Insightful)
Re:A standard tab length would be easier (Score:2)
Because it _cant't_ be significantly better no matter what.
Why do you thing there's still a "tab war" (or a "vim vs. emacs war", for that matter)?
It's because there's no "significantly better" alternative (at least not _within_ then proposed choices).
What (maybe) would be significantly better would be the "standardization by itself". But then, each party will insist on standardize on *his* side, not the
Re:A standard tab length would be easier (Score:2)
Yes, that's the old way.
Re:A standard tab length would be easier (Score:2)
Are you happy? / Cxu vi estas felicxa?
Silly Slashdot and its lack of UTF-8 support
Re:A standard tab length would be easier (Score:5, Insightful)
I actually like this idea, because it actually you from using this seemingly-simple but in actuality horribly complicated idea that tab = x*space. Instead they have an actually simple idea: Each tab is a seperate column of text. Line up items in the same column with each other. (Of course, how simple this is in practice is yet to be deterimined, but it seems simpler to me.)
This idea is actually about seperateing sementic and content info. Programmers use tabs (those who do) to convey sementic info. If we can make the program understand that, then we can offer more flexiblity to the user on how to present the information.
Re:A standard tab length would be easier (Score:2)
Re:A standard tab length would be easier (Score:2)
Re:A standard tab length would be easier (Score:2)
However, it is often done in one specific way, which is easy to use. Hijacking that, and making it both easier to use for the human and more meaningful to the editor would
Re:A standard tab length would be easier (Score:2)
Unless you program Python, of course...
Re:A standard tab length would be easier (Score:3, Informative)
In Vim: Press shift+v to highlight the current line, go to the opening brace, press % to go to the closing brace (highlighting the whole block in turn), then press = to auto-indent.
In command mode, == auto-indents the current line, << and >> indent to right and left respectively.
Back to t
Re:The 1960's called and want their text editor ba (Score:2)
What's not "easy to use" about pressing one key to perform a complex operation. I'm no vi fan, but that sounds easy to me.
(emacs is M-x indent-region, or whatever you've bound that to.)
Re:A standard tab length would be easier (Score:5, Informative)
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 [editplus.com]. 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.
Re:A standard tab length would be easier (Score:2, Interesting)
Tabs versus Spaces: An Eternal Holy War. [jwz.org]
Jamie Zawinski
A very clever solution indeed. Apparently some clever bastard sovled this issue six years ago. Return t
Re:A standard tab length would be easier (Score:5, Insightful)
It's so simple, it's quite embarassing for the whole of the computer-literate society that people still get their kickers in a twist about it.
Anybody who tries to lay down the law by saying that a tab must be 4, 8 or 2 characters' width has missed the point of the tab key completely.
As for your wish, I'm willing to bet money that either vim or emacs will do it for you.
Re:A standard tab length would be easier (Score:3, Insightful)
I'm sure a lot of things seem so simple when you're so ignorant of the actual issue [go-pear.org].
Re:A standard tab length would be easier (Score:2, Insightful)
Wait. Doesn't this miss the entire purpose of tabs?
I like to see my code indented by the equivalent of two spaces. The other coders in my team like to see their code indented by the equivalent of four spaces. Do we engage in massive edit wars in cvs? Do we regu
Re:A standard tab length would be easier (Score:3, Insightful)
Re:A standard tab length would be easier (Score:5, Insightful)
eg: (---> means 'tab', '.' means 'space')
void foo ()
{
--->if (something)
--->{
--->--->/* I like to format my comments so that
--->--->.* the stars make a vertical line,
--->--->.* but I don't care how much you like to
--->--->.* indent */
--->--->bool something = SomeLongFunction() &&
--->--->.................Another()
--->}
}
This code satisfies everybody with a good text editor. If you like 8 spaces, set your editor so. If I like 2, 7 or 3.14 I can set mine. Pressing space n times annoys everybody who likes 2n, n/2 or any other number of spaces.
That way they can get on with arguing over important issues like the placement of {
;)
Re:A standard tab length would be easier (Score:2)
Re:A standard tab length would be easier (Score:2)
I use exclusively tabs for indentation. Then, you can choose to view it in your preferred format. Most people seem to like the equivalent of four spaces for indentation. I prefer two. We can both be happy!
If you're using tabs just for indentation to indicate code blocks then it doesn't really matter if the editor changes it, the code is still perfectly readable. Plus, if you're using a decent editor, you can set the space a tab indicates to
Re:A standard tab length would be easier (Score:3, Interesting)
int foo ()
{
if (
some_really_long_expression &&
some_other_really_long_expression
) {
DoSomethingClever(42);
DoSomethingComplex(
param1,
Re:A standard tab length would be easier (Score:2)
Re:A standard tab length would be easier (Score:2, Interesting)
1.
param2,
if param2 changes (ie, imagine a more complicated line), you waste time re-aligning the comments. Of course, with tabs=3 or 4, you might also need to realign, just not as often.
The other complaint is similar - aligning #defines:
2.
#define Foo 17
#define BARBARBARBAR 18
p
Re:A standard tab length would be easier (Score:3, Informative)
Re:A standard tab length would be easier (Score:2)
Also, if it is a big concern, make use of sed to standardize the code (as best as possible) and then use it again to convert back and forth. It is available for win32
Re:A standard tab length would be easier (Score:2, Informative)
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_
KATE indents groups of "if-else" (say) lines (Score:2)
I don't know if this fits the bill, but KATE (KDE Advanced Text Editor) will indent blocks. Actually, it's the embedded editor in the KDE suite (for which KATE is the front end); I use the simpler KWrite
Re:A standard tab length would be easier (Score:3, Informative)
I thought they had...
[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
Re:A standard tab length would be easier (Score:2)
Re:A standard tab length would be easier (Score:2, Funny)
C-Space C-c } Tab
Re:A standard tab length would be easier (Score:2)
Re:A standard tab length would be easier (Score:2)
Re:A standard tab length would be easier (Score:3, Insightful)
Tab is already standardized. It means either "move onto the next record" in tabular data, or in programming languages "indent". If you have a preference for how much like code to be indented, then you get to set your editor in accordance. Indenting code with tabs is far more considerate than indenting with spaces. Indenting with tabs says "Indent a little. I trust you to set your editor accordingly".
Re:A standard tab length would be easier (Score:2)
E.g.
^---void myFunction(int a,
^---^---^---^---^---int b);
becomes
^-void myFunction(int a,
^-^-^-^-^-int b);
when the tab width is changed from 4 to 2.
The only way to fix this with ordinary tabs and spaces is to insist that the number of tabs in a particular block is kept constant and spaces are added for alignment, e.g. (with . representing space)
^---void myFunction(int a,
^---................int b);
The
Re:A standard tab length would be easier (Score:2)
Re:A standard tab length would be easier (Score:2)
What does TAB sizes have to do with anything, and especially modern programming?
You might be thinking of indentation, and while there was a time where tabs was used to indent because text-editors couldn't redefine the tab key to indentation width; this time has passed, and there is no reason left to use TABs in programming at all.
Word is a shitty text editor. (Score:2)
But code editors they are not.
We brough content folding and syntax highlighting to text editors. Now it's an appropriate time to bring them layout magic, I suppose.
Re:Word is a shitty text editor. (Score:2)
It's not a comment about Microsoft. (Score:3, Insightful)
I've never used it so I can't comment. So it has variable-width fonts and logical indenting and spacing? Good for them.
If it appears in anything _besides_ Visual Studio I'll be a happy camper.
Bad diff (Score:2)
Otherwise I agree with you, and personally I would always opt for a version control system that would let people reformat code whitespace to their liking.
Exception to the rule. (Score:2)
Re:Exception to the rule. (Score:2)
Befunge source is a matrix.
>p.s. Anyone that programs in the whitespace programming language deserves
>what he/she gets when someone else comes along and reformats it
An argument again' Python if I ever heard one
Why indent is not the answer (Score:2)
I recall somebody here mentioning once that he worked at a place where CVS was setup to automaticly run indent on checkin and checkout. This seemed ideal to me--each coder would get to work in their own preferred style. Then I realized the problems it would cause with certain things. In most of my code, when I return an integer error, I use a macro that munges in a number for the file, a semantic error code (e.g., file not found) and--here's the problem--the __LINE__ directive. The beauty of this system
Re:where you missed the point (Score:2)
Think again. Of course you have to enforce a consistant environment for releases; but then you are back to having "one indent to rule them all". I guess you could say that's an incentive for developers to not produce bugs, because if they produce a bug they have to debug it with the release settings, and if they don't like those settings it's more of a hassle. Generally though, we don't want to hassle people.
Re:No, No, It's Not the Length of the Tab! (Score:2)
Or when you edit code and just have to change someone else's layout, do a find-replace on tabs with however number of spaces you want instead?
Re:No, No, It's Not the Length of the Tab! (Score:2)
Re:Source code is not a table (Score:3, Insightful)
Yeah. And this is exactly the way it should be today. In mature Emacs modes for example, pressing the TAB key doesn't necessarily mean that you insert an ASCII TAB character, instead it indents to the right place. Modern editors should take the burden of 'manual' indenting from the coder and instead let him focus on the
Re:What does this solve really? (Score:2)
Y'know, there really ought to be a way to use rot13 on Slashdot so that innocent eyes wouldn't have to see things like that. Think of the chillllllllllldren!