Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid
 
PerlMonks  

Tabs vs Spaces lets give this a go

by EvanCarroll (Chaplain)
on Oct 08, 2006 at 04:50 UTC ( #576936=perlmeditation: print w/replies, xml ) Need Help??

My arguement in favor of tabs

OK this is really getting on my nerves, not that people don't follow my convention, as much as people thinking their wrong convention is more righteous than mine. So I'm going to sum up the case, of spaces vs. indentation. I'll start out this diatribe by stating this is pro-tab, and DC is undeniably wrong, this is the most blatant flaw in the PBP.

  1. Tabs belong in one place in a document; and that place only. That place is in between the left-margin and the first word character. This is the tab-zone.
  2. Nothing other than tabs, belong in this tab-zone
  3. This tab-zone encodes not display, but tabs as code-metadata, the level of indentation for your code or depth, which for my purposes can be used interchangeably.
  4. This metadata can be utilized by external code preprocessors, editors, renderers, searching mechanisms or anything of that sort.
  5. Because you are encoding a level of indentation rather than an element of presentation everyone with a decent modern editor can have their cake and eat it too. ie. you can set your presentational tab-space, or tabspace to 2, your friend can set it to 4, or you can have a script based on the time of day alternate it. It doesn't mater. This will eliminate the conversion toandfro spaces. Changing this indentation will still permit all operators to line up, they will just be shifted more, and that shift will be linear to their level of indentation.

Let me explain further why this metadata is important. Lets say you want to target where in your document the sub foo {} is. You preform a search on google.com's nifty codesearch, it yeilds what? foobar.pl, line 50, char X.

Should X include those spaces, or not? If so how many should it assume for each level of what appears visually as indentation? Should it display depth? You might make the argument that a line should only be 80characters? (or 78 if you are an O'reilly author who likes to justify modern coding practices with terminals from the 60s'. But thats alltogether a different argument, to which I personally subscribe, but because of preference rather than false-reasoning. ) The answer is oblivious to the length of the line, whither it be 5000 characters or 50 characters, the x-axis is important, and by using spaces to encode depth as presentation you are dually losing data, you no longer know the level of indentation, and you now have to assume what the programmer meant through heuristics.

This is all a fault of spaces, and the lack of a universal space->depth variable, but then again, spaces are being used in this context to alternate the presentation, which is fundamentally wrong. Another thing I would like to point out is something the space-proponents like to take advantage of, and it is often moot because it is an undeniable evil, and that is spaces do mark something up, and that is something we all use  @words = split ' ', "foo bar baz" it is unfortunate we use them at all for presentation. But lets not make the same mistake for tabs.

Now finally the catch, I admit there is one thing I have neglected. The only fault in this argument is minor and disappearing more every day, and that is legacy editors, or non-programming editors. Lets be blunt now:
Qualitatively how useful is a programmer who uses notepad?, What does it say about a programmer who uses notepad?, How productive can the programmer be if he opts to use tools that are so inept in the productivity dept?

You are only as good as your tools, "\t" is one that shouldn't be neglected.

I have removed responses from this node and added them to subnodes to satisify the node's fans.



Evan Carroll
www.EvanCarroll.com

Replies are listed 'Best First'.
Re: Tabs vs Spaces lets give this a go
by GrandFather (Sage) on Oct 08, 2006 at 06:03 UTC

    Tab characters should never be used in source code. They are far too prone to being abused. Traditionally a tab character was 8 spaces wide. Almost no one uses 8 character indents so a common convention is to set the expansion width of tab characters in editors to the indent width currently being used. After a little editing some of the indent tabs will turn into spaces. After that all hell breaks loose when you share the code with a friend or workmate.

    At least space indented code is presented in similar fashion by virtually all rendering systems. That is not true at all for tab indented code.

    If you have a real need to alter the indentation of space indented code use a pretty printer appropriate to the language it is written in. If there isn't one available you could pretty quickly write a Perl script to figure out the indent quanta and change it to your preferred size.

    Remember the golden rule - never use tabs for indentation.


    DWIM is Perl's answer to Gödel
      Tab characters should never be used in source code. They are far too prone to being abused.

      Perl is also prone to being abused, should we swich to python?

      :-)
      Remember the golden rule - never use tabs for indentation.

      The golden rule is never mix the twp and everyone is happy.

        No. Perl is abused in amusing and educational ways. Python uses indentation in obscene ways that exacerbate the tab issue beyond reason. :-)

        Actually the golden rule is: "He who has the gold rules". All Evan actually has to do is get enough money then he can pay everyone to follow his style guidelines and have shot anyone who doesn't.


        DWIM is Perl's answer to Gödel
    A reply falls below the community's threshold of quality. You may see it by logging in.
Re: Tabs vs Spaces lets give this a go
by xdg (Monsignor) on Oct 08, 2006 at 09:51 UTC

    Wow. There are so many things wrong with this post that I almost want to consider it to be marked a troll. I'd say someone hacked your account to hurt your XP, but too much energy seems to be put into the post for that. I appreciate that you feel "righteous" but I think your energy is misplaced on this one.

    I'll start out this diatribe by stating... this is the most blatant flaw in the PBP.

    That's almost worth a "--" right there. PBP has a lot of great recommendations, but of the blatantly bad ones, tabs vs spaces can't possibly beat recommending half-a-dozen or so brand new CPAN modules and declaring them "best practice". (With Class::Std being my personal least-favorite among them.)

    tabs as code-metadata

    Metadata should derive from the data -- it shouldn't drive the data. declaring "tabs are better" so that people can search code by indentation level is one of the most bizarre justifications I've ever heard. Code-search should be one of the last considerations for code formatting choices.

    For me -- it comes down to simplicity. Too many things need to go right for tabs to work properly the way you describe. You have to have a smart editor. You have to only use tabs to your indentation level and then you have to use spaces for any alignment after that. That's too easy to get wrong. (Plus you have to think about it.) And everyone you share code with has to get it right as well.

    -xdg

    Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

Re: Tabs vs Spaces lets give this a go
by ioannis (Abbot) on Oct 08, 2006 at 06:09 UTC

    The tab character is not a meta-character. It belongs in the group of 'control' characters, the first 32 codes as ASCII, whose historical mission was to control the the output device; as such, the meaning of each control character varies for each device -- for example, a printer will advance the head horizontally, but another device might do something different.

    As for code, I agree with you philosophically; although, the is always the danger when code is passed around for the tab character to transform into either a single space, or into 8-spaces. Spaces are never candidates for transformation, but tabs travel with danger.

    A reply falls below the community's threshold of quality. You may see it by logging in.
Re: Tabs vs Spaces lets give this a go
by chargrill (Parson) on Oct 08, 2006 at 06:09 UTC

    Personally, I don't agree with you. I agree more with TheDamian and Grandfather. Honestly though, I developed the preference for spaces so long ago that I've forgotten exactly why I prefer spaces to tabs.

    However, you present your ideas pretty clearly and logically and made me examine my own thinking on the subject, so I upvoted you.

    And I raised this discussion on IRC, where I think the main idea is this: overall (and not just this particular topic) PBP recommends picking a convention and sticking with it. If you share his preference for spaces, awesome for you. If you prefer tabs, just make sure your whole organization does too. :)



    --chargrill
    s**lil*; $*=join'',sort split q**; s;.*;grr; &&s+(.(.)).+$2$1+; $; = qq-$_-;s,.*,ahc,;$,.=chop for split q,,,reverse;print for($,,$;,$*,$/)
      I, too, had forgotton why I had firmly moved into the anti-tab / pro-space division until last week.

      I was given the task to maintain a piece of software. As any good software engineer would do I kept to the original conventions of this software; as much as I don't like tab-indented code I continued to use tab indents to maximise maintainability of this particular piece of code and to minimise the diffs when checking in changes.

      Unfortunately I got my editor to tabify my section of the code (as I use space indent by default). The trouble with that is that it converted a string of 8 spaces "        " into "\t". Lucky for me we had automated tests that flushed this problem out!

      To protect myself against this kind of thing I've kinda resolved personally to encode spaces in strings as "\x20".

      But don't be fooled.. tabifying code is horribly inconsistent and prone to much danger. It's bad.

    A reply falls below the community's threshold of quality. You may see it by logging in.
Re: Tabs vs Spaces lets give it up
by derby (Abbot) on Oct 08, 2006 at 11:29 UTC

    With tools like perltidy why should one care? I've given up on trying to browbeat errant devs about proper style and I just filter code through perltidy.

    My evil master plan is to hook perltidy into our version control system so then I can say - "I'll take a look at your code after you check it in."

    -derby
Re: Tabs vs Spaces lets give this a go
by talexb (Canon) on Oct 08, 2006 at 09:57 UTC

    Evan, like I said in #perl on IRC a few hours ago, I respect your right to be hard-core, but the way arguments are discussed on Perlmonks is that you respond specifically to each argument, rather than updating the root node. That way, another can follow the various paths of conversation.

    Normally in this tytpe of situation (a controversial suggestion, discussed with reasoned reponses), I upvote the root node for bringing up an interesting discussion and, if absolutely necessary, downvote any replies I violently disagree with, or think are not at all helpful or downright inaccurate to the majority of other readers. But your refusal to follow the usual and customary discussion protocol made me decide a downvote was appropriate.

    And don't worry about XP -- if you're passionate about a subject, just go ahead and write, and let the XP fall where it may.

    Alex / talexb / Toronto

    "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

      point well taken.

        Good job on removing the replies from the root node and reditributing them where they belong. Thanks.

        Alex / talexb / Toronto

        "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

Re: Tabs vs Spaces lets give this a go
by demerphq (Chancellor) on Oct 08, 2006 at 12:15 UTC

    All I know is that the major advantage of tabs is that they reduce source size, beyond that they make a lot of things difficult.

    For instance your editor groks mixed tabs/spaces and interconverts on indent/outdent as appropriate. But my editor either uses a tab or uses some number of spaces, and for reasons unknown decides that the appropriate place to insert its "indent string" is at the front of the line. End result? When I try to outdent your code it doesnt work properly, as 4 spaces + a tab is visually the same thing as a single table when the tab is defined to be 8 chars long. Which it has to be if you are working with code that comes from editors that do the evil tab/space thing.

    I routine encounter this problem, and I routinely mutter about it, as often the perl patch pumpkings convert my space indented code back to tab indented code before the apply the patch, so even my own code mysteriously ends up having fucked indenting properties in my editor when i go to change stuff. Necessitating me to convert the code back to spaces, blah blah.

    Even worse is when you work with people whose idea is to change the size of a tab, which is just a nightmare when people on your team all have different ideas on how big it should be. Inevitably people use spaces instead of tabs _sometimes_ and then you end up with indenting problems.

    So I'd say that in the interest of maximum interoperability and minimum hassle use spaces instead.

    ---
    $world=~s/war/peace/g

Re: Tabs vs Spaces lets give this a go
by tilly (Archbishop) on Oct 08, 2006 at 20:25 UTC
    While I laud your desire to clearly articulate your programming opinions, I must point out that someone who just discovered revision control probably has something left to learn about good programming practice. Therefore when you find yourself on the opposite side of a style debate with most of the programming world, you should seriously consider whether or not this is because the rest of the world knows something that you do not.

    I already stated in Re^3: Tabs vs Spaces lets give this a go why I personally prefer space based indentation over tab based indentation. That answer included several things that you did not address in your post. Including the needs of people who use many machines, shared accounts, and the practicalities of dealing with people who are not already acting in accord with what you want. To me those outweigh the minor advantage of having different programmers who want to view the same code with a different level of indent.

    Particularly since it is my opinion and experience that it is easy for competent programmers to adapt themselves to the locally-popular indentation style. Particularly when they're going to have to adapt themselves to the locally popular brace style anyways. (If there is no consistent locally popular style, then you have bigger problems...)

    A reply falls below the community's threshold of quality. You may see it by logging in.
Re: Tabs vs Spaces lets give this a go
by jbert (Priest) on Oct 08, 2006 at 14:11 UTC
    A consequence of your first two points:
    1. Tabs belong in one place in a document; and that place only. That place is in between the left-margin and the first word character. This is the tab-zone.
    2. Nothing other than tabs, belong in this tab-zone
    is that you can't do any vertically-aligned code. For example, if you want to split a long while- or if-condition onto multiple lines, you can't align things for readability in such a way which is tab-width agnostic.

    So, I would disagree with your point 3. Not every line of code has an explicit indentation level, in particular continuation lines do not.

    I prefer space indentation for these reasons.

    A counter argument could be made that such long lines are always bad, or that one should use a sufficiently wide line and so that line-splitting is never necessary. But you'd need to establish that point before having a tab-v-space argument, since the 'pro tab' position depends on it, I think.

      Generally, what he means is to "tab" until you get to the indentation level for an ordinary line at that point, then use spaces after that for justifying continuation lines. E.g.:

      # "--->" is a tab and "." is a space: --->{ --->--->if ( really_long_condition_here() && --->--->.....another_really_long_condition_here() ) # see spaces on t +his line --->--->{ --->--->---># do stuff here --->--->} --->}

      That way, you can adjust the tab display size, but the alignment is preserved.

      I personally can't stand it, but that's the approach the tab-advocates suggest.

      -xdg

      Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

      A reply falls below the community's threshold of quality. You may see it by logging in.
    A reply falls below the community's threshold of quality. You may see it by logging in.
Re: Tabs vs Spaces lets give this a go
by mreece (Friar) on Oct 08, 2006 at 07:03 UTC
    what really drives me nuts is editors that like to write 4 spaces for one indent, tab character for two.

    the more general problem with tabs is that someone invariably is going to want to indent a wrapped line an additional 6 spaces and is going to do it with a tab and two spaces, and someone else is going to try to display tabs as 3 spaces and it won't line up.

    it may not technically even violate your rules above (tho 5 is ambiguous enough it may apply).

    you've also taken away the ability to use the tab key to speed the alignment of tabular arrays.

    to say, i agree in principle, but not in practice. the easiest way to get consistency is to restrict freedom -- soft tabs only, 4 spaces per indent.

    A reply falls below the community's threshold of quality. You may see it by logging in.
Re: Tabs vs Spaces lets give this a go
by zentara (Archbishop) on Oct 08, 2006 at 12:46 UTC
    What are you trying to do, turn Perl into Python? Those f**king tabs are what turned me off to Python right from the start.

    I upvoted you though, for having the guts to speak your dangerous thoughts. :-)


    I'm not really a human, but I play one on earth. Cogito ergo sum a bum
Re: Tabs vs Spaces lets give this a go
by halley (Prior) on Oct 09, 2006 at 15:04 UTC

    It's just a rite of passage that a newcomer to the field of computer programming must explore. In your words, "let's be blunt now."

    • argue their unflagging, nee unflinching support for one side of a useless style standards discussion
    • loudly expouse the virtues of their own code editor over all others, of which maybe a third of the useful features have been explored adequately
    • rally for the adoption of an obvious workflow advantage such as using centralized source code repositories
    • create and standardize on a new and smarter "string" class which only serves as a standard for one project

    For me, if I have to use an editor which makes me even THINK about tabs versus spaces, I feel like a caveman eating mammoth meat off the bone. A good editor will just adapt for you, and adjust the indentation to each likely point of visual indentation for you, and save it with the appropriate encoding automatically. That's all it is: an application-specific encoding of whitespace, and therefore, an almost entirely uninteresting implementation detail.

    And for that one guy who advocated them for the purposes of reduced file size, please go buy another 10MB winchester or bernoulli box down at Radio Shack before you tear the 1983 calendar off your wall.

    Thanks for separating out the responses. It gave more voting exposure.

    --
    [ e d @ h a l l e y . c c ]

Re: Tabs vs Spaces lets give this a go
by shmem (Chancellor) on Oct 08, 2006 at 12:26 UTC
    You are only as good as your tools, "\t" is one that shouldn't be neglected.
    You might be right on all your arguments (solomonically spoken), here you are wrong. A "\t" isn't a tool, it's material, if anything. I use it a lot in regular expressions ;-)

    Tabs, spaces, whatever - having an editor which DTRT (and that's even vi on good ol' SunOS4, though not on early HPUXen) I simply adapt to what style's at hand. Just keep yourself flexible and focus on the real problems in life ;-)

    BTW - I never ever try to impose my personal preferences on others, be that by ways of persuasion, argument, or force.

    --shmem

    _($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                                  /\_¯/(q    /
    ----------------------------  \__(m.====·.(_("always off the crowd"))."·
    ");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}
Re: Tabs vs Spaces lets give this a go
by hossman (Prior) on Oct 08, 2006 at 08:45 UTC

    Those who are interested in this topic may want to consider Elastic Tabstops (which seems to be esentially what EvenCarrol is argueing for, allthough i'm not entirely sure since I did not consider his arguments carefully because I am not one of the people interested in this Holy War)

Re: Tabs vs Spaces lets give this a go
by Hue-Bond (Priest) on Oct 08, 2006 at 09:13 UTC
    So as not to have to withstand the brunt of multiple downvotes from the same people, I have added responses in the main thread

    Then you are going to get downvotes from other people (me, for example). Replying in your main node will make it difficult for everyone to follow the conversation and, which is worse, to contribute to it. If you want to avoid being downvoted, there are better ways to do it, like posting as anonymonk (not that I'm recommending it) (Update: OP removed the replies and posted additional nodes so this no longer applies).

    FWIW, I use tabs yet. I plan to switch to spaces Real Soon Now.

    --
    David Serrano

Re: Tabs vs Spaces lets give this a go
by radiantmatrix (Parson) on Oct 13, 2006 at 15:53 UTC

    God, I hate this stupid war. Especially when it comes to Perl, if for no other reason than the existence of Perl::Tidy makes conforming to either choice a simple matter.

    Or, as the OP says:

    everyone with a decent modern editor can have their cake and eat it too.

    Every reasonably modern editor can look at code written in either a space-indent style or a tab-indent style and present it in a sensible way. The only thing that really matters is that you preserve the existing style of code you edit to make for readable diffs. And with modern editors and perltidy, this is a very simple exercise.

    (I admit, I have a preference for tabs: it's based on my own personal pedantry that when I press tab, damnit, I want a tab and not an interpolated set of spaces. But I clearly don't possess enough hubris, as I will simply use whatever style the code I'm working on embodies.)

    <radiant.matrix>
    A collection of thoughts and links from the minds of geeks
    The Code that can be seen is not the true Code
    I haven't found a problem yet that can't be solved by a well-placed trebuchet
Re: Tabs vs Spaces lets give this a go
by CountZero (Bishop) on Oct 08, 2006 at 16:49 UTC
    Just use a modern code-editor (such as Komodo) which can tabify or untabify your code at will and does a great job of aligning your opening and closing brackets in such a way that you get very neatly looking code irrespective of using tabs or spaces.

    To me this discussion lokoslooks to be of the "what is the sex of an angel" kind.

    CountZero

    "If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law

Re: Tabs vs Spaces lets give this a go
by pdcawley (Hermit) on Oct 10, 2006 at 10:03 UTC

    In the case of an unwanted pregnancy, there's a three way choice: abort; keep the baby; give it up for adoption.

    All the choices are wrong, which makes choosing the least wrong one in your particular circumstances very hard indeed.

    Choosing your code indentation style is unlikely to have such a devastating effect on the lives of at least two people, but there's a strong case for saying that all the available choices are wrong as well.

    The best choice to make is the one your teammates (or your team leads) make. If you have the tools to let you code in your favoured style and then convert back to house style, good for you. If you don't, you live with house style.

    So, I have a preference certainly (spaces throughout), but it's not The Right Answer. Nothing is.

    Arguing that your way is the One True Way is already laughably futile. Arguing that it's the One True Way because it adds valuable extra metadata, when that 'metadata' can be worked out by any code editor worth its salt (or delegated to perltidy) would appear to plumb the very depths of futility. Well done.

    Someone give that man a bathyscaphe.

Re: Tabs vs Spaces lets give this a go
by jdporter (Canon) on Oct 09, 2006 at 19:16 UTC

    Clearly, the solution is to use one-space indent.

    Its only downside is that one column of indent can be hard to distinguish readily by eye.

    I'm half serious about this argument.

    We're building the house of the future together.
Re: Tabs vs Spaces lets give this a go
by monarch (Priest) on Oct 08, 2006 at 22:45 UTC
    My feeling is that code is not meta data, rather it is a work of art in some respects. Whilst a compiler doesn't see it that way (code is code) a human, on the other hand, demands presentability, readability, maintainability. A human has to diff the code, has to have comments, and has to abide by coding conventions in a work place in order to make collaboration on a project easier. These things are not meta in any way!

    A programmer's canvas is plain old text. Usually monospace. The difference is that a word processor has a different canvas - that canvas has multiple fonts, proportional spacing, and tab stops that align paragraphs.

    By realising that the programmer's canvas and the word processing canvas are two different things we can come to realise that the tab character (\t) is prone to creating more problems than it solves for programmers who are attempting to paint on a canvas that alters shape between user experiences whenever a tab character is involved.

    A reply falls below the community's threshold of quality. You may see it by logging in.
Re: Tabs vs Spaces lets give this a go
by Anonymous Monk on Oct 09, 2006 at 05:31 UTC

    For all your posturing about good logic, there is something glaring in your post that belies your boasting:

    I admit there is one thing I have neglected. The only fault in this argument is minor and disappearing more every day

    Set up the opposition's argument, and knock it down. It was so easy to knock down, wasn't it? But it's not actually a good representation of the fault in your position. Thus what you have so easily knocked down is actually a straw man. It makes you feel like you've taken care of the opposing case, and looks like that upon casual inspection, but in reality it is a pointless rebuttal indeed. Nice try, pal.

Re: Tabs vs Spaces lets give this a go
by xorl (Deacon) on Oct 09, 2006 at 12:55 UTC
    Interesting. In 10 years of programming, I've never encountered someone who uses spaces to indent code. I'm truly shocked by the number of people here who use spaces.

    I've not taken many CS clasess, just one here and there as required by work (and none at the same college). All of them wanted the code indented and wanted tabs used.

    To me tabs offer 3 things that spaces don't:

    1) smaller file size

    2) easy to change the with in the editior by just changing the location of the tabstops.

    3) who the heck is going to want to count out 16 or 32 spaces when you can just hit tab 2 or 4 times?

    Thoses are my reasons. I'm sure other people will have other reasons.

    The more interesting thing about this thread is the strong feeling it seems to have evoked. I really don't understand it. If your shop uses spaces, use spaces. If it uses tabs, then use tabs. If you're lucky and work in a small one man shop, then use whatever the heck you want or maybe don't even indent. This shouldn't be such a big deal.

    Let's all take a deep breath and count to 100 before anyone makes another post.

      1) Smaller file size is a negligible advantage nowadays IMO. 2) Yep, that's usually true. 3) Surely you are joking! Any half-decent text editor that lets you choose spaces for indentation will use the tab *key* for indentation, but producing the right amount of space *characters* on the file. It will also support autoindent, and maybe even "smart" autoindent (although I personally hate the latter).

      In my experience, although the argument for tabs is pretty logical, it doesn't work that well in practice. Years ago I thought a lot about the issue, decided to use tabs, and configured my system accordingly. It ended up being a lot of trouble whenever I interacted with anyone else or got source code from anywhere else. Even without interacting with other people's code, I had trouble because I was using a variety of programs on a variety of platforms, and not all of them let you configure the tab stops (or it wasn't worth the time). I switched to spaces and I've been much happier ever since. :-)

Re: Tabs vs Spaces lets give this a go
by Anonymous Monk on Oct 08, 2006 at 20:59 UTC
    The people that argue in favor of spaces based on which editor they use are probably also the ones that bemoan the difference in javascript implementations because they can't just stick with browser that most people use. A good editor makes it so you don't care if they are spaces or tabs. Do you decide how to do things, or do you lt your tools do it for you? Who's the one with the brain? You or the editor?
      "A good editor makes it so you don't care if they are spaces or tabs."
      And a good developer DOES care because he knows he and his fellow supereditor might not be the only ones working with that file :)

      Ordinary morality is for ordinary people. -- Aleister Crowley
Re: Tabs vs Spaces lets give this a go
by friedo (Prior) on Oct 08, 2006 at 06:09 UTC
    The OP is so blatantly incorrect that it defies description. Tabs are useless, and if I had my way, the tab button would be pried loose from every keyboard in the world and hurled into the firey depths of a giant volcano.

      Actually the tab key I use all the time - generally it translates to "indent this line the appropriate amount". The tab character should be bannished as you suggest, except perhaps as a separator in csv files.


      DWIM is Perl's answer to Gödel
        Agree. I need the tab key to type two or more spaces (depending on things I edit, perl gets 4, ordinary text gets 2, html gets 1) by one stroke. Well, at least in vim. It also allows me, at the same time, to enter insert mode from normal mode. Yes, I could remap, but I use the key for nothing else. Oh, I'm used to cycle those windows with Alt-Tab. It's really nice to have this in X.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://576936]
Approved by planetscape
Front-paged by brian_d_foy
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others chanting in the Monastery: (6)
As of 2020-07-12 21:48 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found

    Notices?