Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×

Elastic Tabstops — An End to Tabs vs. Spaces? 263

Posted by timothy from the stretchy-logic dept.
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!"
This discussion has been archived. No new comments can be posted.

Elastic Tabstops — An End to Tabs vs. Spaces? More

Elastic Tabstops — An End to Tabs vs. Spaces?

Comments Filter:

  • From Wiki (Score:5, Funny)

    by neonprimetime ( 528653 ) on Monday July 03, 2006 @03:16PM (#15651732)
    Use of the term "Holy War" implies that the root of the disagreement is a clash of values, and intractible of resolution except by agreeing to disagree.

    My bible says it is morally wrong to use Vi.

    • Re:From Wiki (Score:3, Insightful)

      by Kesch ( 943326 )
      :s/Vi/Emacs/g

    • Re:From Wiki (Score:3, Funny)

      by jc42 ( 318812 )
      My bible says it is morally wrong to use Vi.

      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)

      by DesertWolf0132 ( 718296 ) on Monday July 03, 2006 @03:44PM (#15651948) Homepage

      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)

        by Ed Avis ( 5917 )
        Nope, afraid not. vi is a modern-day abomination. Ed is the standard text editor. [gnu.org]

      • Re:From Wiki (Score:3, Informative)

        by kimvette ( 919543 )
        However, in the second book of Coders, 1:2-5, we find the following:

        2 And BOFH called a little coder unto him, and set him in the midst of them, 3 And said, Verily I say unto you, Except ye be converted, and become as this emacs user, ye shall not enter into the kingdom of unix. 4 Whosoever therefore shall humble himself as this little coder, the same is greatest in the kingdom of unix. Then were there brought unto him other little coders, that he should put his hands on them, and give them emacs: and the a

        • Re:From Wiki (Score:2, Informative)

          by DesertWolf0132 ( 718296 )

          You left out verse six:

          6. And behold the emacs did vex their souls for the BOFH hateth the coder who is loathe to select and compile an editor unto himself and loveth those who shalt compile for themselves the holy Vi. Yea verily I say unto thee that from that day those coders fell into error such that the BOFH sayeth, "This bringeth joy to my soul as great as the Holy Lager, that these coders might vex themselves with that which is unclean." 7. And the BOFH did laugh much at the pain he hath sent out upo

      • There it is in black and white. Vi is the way of truth and light. All others are unclean.

        Fi on vi! Emacs forever!

    • Hmmmm I went searching for "The EMACS Bible" book... figuring that it was the bible you had to be referring to but was confounded by the fact that one apparently doesn't exist... so maybe you've got a copy of a Lost Translation or something...

      ...closest i could find was the The Linux Bible: The Gnu Testament [amazon.com] - so maybe this is what you were referring to ;-p

  • How we got here (Score:5, Interesting)

    by Animats ( 122034 ) on Monday July 03, 2006 @03:18PM (#15651741) Homepage

    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)

      by Mr Z ( 6791 )

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

    • You do realize that turning off the styling is as simple as selecting all the text, then changing to one standard font at one standard size?

      Not that I'm for it ... well, maybe a little. It would be nice to have bold and italic.
    • I think that this is good, I aways thought that tabs for identation is simply a better idea just because it made simple for people to see the code the way they feel more conforable with. I don't think 'styles' is a problem, it is just the oposite, imagine if we could make a "style sheet" of some sort and apply to the code and sudenly all the code you load into your editor is styled as you liked?

      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
      • "imagine if we could make a "style sheet" of some sort and apply to the code and sudenly all the code you load into your editor is styled as you liked?"

        Yeah, but people would still screw it up. For example:

        // K&R style -- comments on the if/else go before
        if () {
        // comments on the if clause go after the first {
        } else {
        // comments on the else go after the else {
        }

        // BSD style
        if ()
        {
        }
        else
        {
        }

        # Conway style
        if () {
        }
        # This also is a problem with BSD, but I thought I
  • Tabs have been and should continue to be what they are. If you need to format code within the 8 spaces, then use a tab. Otherwise use a space. In no other way can we get source code that looks consistant across editors and platforms. Especially in neat languages like python. Attempts to redefine tab stops are misguided. And don't even get me started on the use of proportional fonts in programming editors. Heresy.
    • Wrong. A TAB represents 1-N spaces, depending on the current column, where N is the tab setting. I've never seen a TAB interpreted as a fixed number of spaces, and I've seen a lot of output devices in the 40 or so years I've been playing with computers. TABs move the output position to the next tab stop, not some fixed number of spaces.

      • Correct. By convention, almost all character editors make tab stops by default to be every 8 characters. Therefore 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. This is what I meant. Thus the whole idea of fudging with the tab stops and using code formatters to replace tabs with spaces is a poor idea, as you imply.
        • Yeah, except in the printing industry, where fixed-width fonts are nearly unknown. If you open random printed books, you'll find indents that range from 2 to 6 ens, depending entirely on the whims of the publisher.

          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
    • I can grudgingly accept the arguments of the web site mentioned in the summary, but I am not convinced their solution is the answer. Certainly it will only work if *all* text editors work that way. And that is not likely to ever happen.
  • Start up his Java editor, and replace the line:

    [TAB]if (1)

    With the line:

    [TAB]if (this_sucks())[TAB]/* Always returns true */

    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.

    int myfunc(int arg1,
    Class arg2) /*

  • (setq-default indent-tabs-mode nil)

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

  • What a great social engineering trick - get 30% of Slashdot readers to locally execute untrusted code with local thought. Cracker, my hat is off to you!
  • 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) ^^

    but it is hoped that many editors will be updated to support this new way of interpreting tab characters

    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 enough to everyone.

    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)

    by morrison ( 40043 ) * on Monday July 03, 2006 @04:53PM (#15652358) Homepage

    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:

    /*
    * Local Variables:
    * mode: C
    * tab-width: 8
    * c-basic-offset: 4
    * indent-tabs-mode: t
    * End:
    * ex: shiftwidth=4 tabstop=8
    */

    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)

    by Spudley ( 171066 ) on Monday July 03, 2006 @05:33PM (#15652564) Homepage Journal
    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)
  • Actually, this does sound superior to me over the first two (especially for something like Python where indentation is meaningful).

    But if you thought we had holy wars now, just imagine the nightmare that a third option will introduce...
  • As far as I've come into contact with developers there never has been the slightest doupt what the right thing is. Tabs where introduced as the solution to this very problem. The only problem is that ancient vi and emacs aparently can't deal with them properly. Or their users sometimes are to lazy to set them up properly. The big problem is when experienced professionals follow suit with some blockheads and a few years later themselves insist on everybody using spaces at any time.
    Why should everybody degrad

  • Uh... ok... (Score:4, Funny)

    by zizzo ( 86200 ) <.moc.oohay. .ta. .tlobhsif.> on Monday July 03, 2006 @06:59PM (#15653087) Homepage
    I read the article and played his demo. I'm not excited by this at all for 2 reasons: it invents yet another model of tab spacing and it encourages use of tabs.

    Tabs just need to go away so we can get back to real debates, like CR vs. CR/LF vs. LF.

  • Before veiwing any text documents, editors should have a optional transformation on startup, ripping away anything that doesn't conform to a users preference. For example, on c source files, the editor could run the text through a source formatter, presenting it to the user exactly the way he/she likes it to be set.

    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.

Slashdot Top Deals

What is research but a blind date with knowledge? -- Will Harvey

Close