4 ms·

The problem is that many people and many editors conflate the 'tab key' and the ASCII TAB character. Both Emacs and Vi correctly allow you to indent by 4 space

• cocoflunchy 13y ago
  Just add "translate_tabs_to_spaces": true to your Preferences.sublime-settings to have spaces instead of tabs in Sublime Text.
  • cjensen 13y ago
    That doesn't work if I'm editing a TABs-Are-8 file and still want to be able to indent by 4.
• kstrauser 13y ago
  I'm using ST3 (and ST2 before that) with the default tab handling options, and it inserts spaces and not tabs. I don't think it'd have the rapid adoption among Python programmers if it didn't.
• adamtj 13y ago
  I prefer not hitting tab at all because my editor already knows how far to indent. But when it does indent, I like it to use tab characters as a way to distinguish semantic indentation from alignment indentation. And because emacs and vim are still "dumb" editors in some ways: They still conflate the arrow keys with "move one character", when they should really mean "move one character, unless you are in non-alignment indentation, in which case move one level of indentation, which happens to correspond to four spaces since this particular file is python." They have similar problems with backspace and delete, regexes and search/replace, etc. Further, what if you prefer 2 or 3 space indentation? If you use semantic tabs, you can have that simply by changing the display width of the tab character. It needn't be equivalent in width to 8 characters. To my knowledge, emacs and vim are both too dumb to display code indented with spaces at a different indentation width than saved in the file. Note that when using semantic tabs, tabs only represent semantic indentation. A new block adds a tab. Further indentation for the purpose of aligning multi-line statements must be done with spaces. Tabs following spaces on a line are always wrong. Tabs are not to be used to align to columns. If you want to do that, use spaces. For example: def foo(): --->if (long_named_function_that_returns_a_boolean() and --->....thing2() and thing3()): --->--->do_stuff() And again, with your editor reconfigured to display tabs as two characters wide: def foo(): ->if (long_named_function_that_returns_a_boolean() and ->....thing2() and thing3()): ->->do_stuff() Basically, tabs get you several niceties with partially-dumb editors like emacs or vim. Indenting with spaces gives that all up and all you get in return is the ability to view code with notepad.exe.
  • sesqu 13y ago
    The only exception to that rule that I personally make is indenting in-line comments; I've found that some comment-heavy code benefits from alignment, but multiparagraph alignment is a futile and counterproductive goal, so the tab mark is a good fit.
  • eevee 13y ago
    I prefer not to have to juggle invisible characters when editing plain text.
    • Qantourisc 13y ago
      Tabs are visible in my editor. And so are the spaces at the end of a line it's sweet: :set listchars=tab:\|·,trail:·
      • eevee 13y ago
        Isn't it a little self-defeating to make indentation visible? The whole idea is that it's easy to pick out blocks by the shape of the left margin, i.e., where the first visible character is. If your indentation scheme only works when configuring your editor to mark whitespace, we might as well go back to MUMPS and indent with dots.
  • hobb0001 13y ago
    > Further, what if you prefer 2 or 3 space indentation? This, alone, is why I always use tabs, no matter what any style guide says. People have different tastes. Using tabs allows any editor to indent according to personal tastes.