Hacker News Reader

Hacker News

Comment by raverbashing | Hacker News Reader

Parent Full thread

raverbashing

The only thing that makes me really sad is the aversion to tab indentation

I get it, it looks nicer with 4 spaces. I'm still not convinces it's a straight win.

(Of course, you should never mix tabs and spaces, and I'm glad Python 3 enforces this)

View on HN

I'm one of the few guys who prefer tabs to spaces... but I actually find this change welcome:

before, some people criticized my choice believing that the PEP8 favored one of the 2 approaches, when in fact it just acknowledged that spaces were used more often, and in no case that was an excuse to change pre-existing code... there was some confusion

At least now I can/have-to concede that there's one preferred way

OTOH: I still find subpar the handling of space indentation in most editors nowaday (emacs, vim, gedit... you name it: they all behave similarly)... I could write some emacs-lisp to make the editor behave as I wish, but I never found that hitch worth scratching enough

What is the problem with space handling that makes it sub-par?

More keystrokes when navigating the code

(I know, if vim was second nature to me, this point would probably be moot... but I'm still using the arrow keys a lot :) )

In vim, you can have the tab key print 4 (or n) space characters, have movement keys jump over the 4 spaces like they would with tab characters, and delete the 4 spaces with one keystroke the same way. I don't remember the settings right now but I'll add them to this post when I get home.

please do... when I looked it, I was only able to find how to insert n spaces, and delete n spaces with a single keypress, but I sorely missed the ability to have the arrow keys jump :)

Actually, I'm not sure if I figured out how to make the movement keys treat spaces as tabs, I guess I normally end up using 0/b/$/^ if I need to navigate around them (sorry!). These settings are what I use, and will at least change backspace to delete 4 spaces in one keystroke instead of 4, which is what always annoyed me most.

    set tabstop=4
    set shiftwidth=4
    set softtabstop=4
    set expandtab

The point is also moot in Emacs. What editor are you using that forces you to navigate one space at a time rather than being able to at least jump around by word?

I use vim. When indenting with tabs, I can use "x" (delete one character) to remove a level of indentation. When indenting with spaces, I can't. The dedent command is more verbose than just hitting "x". If I forget when working in a file with spaces, then I have a three space indent. That off-by-one-character is harder to see and correct than a giant missing tab.

Why have one of the most common semantic units in source code (indentation) represented by four characters when there is an otherwise unused character that has already great editor support. Tabs work well in every editor I've used (except notepad.exe, which can't change their display width). Spaces only work well in smart editors.

In vim, ">>" and "<<" will indent and dedent the current line. It doesn't work with spaces and tabs mixed in with the line though. Bonus is you can do things like "10<<". This works even better with ":set rnu" turned on.

Rebind dedent to a little-used key, perhaps? I don't dedent so often that hammering a key twice is a big deal, though.

Editors aren't the only place code appears. I see it in my terminal, in git, in various web-based tools, in email, in browser textareas, etc. I don't want to reconfigure all of these things to make your code look like you see it (if they're even possible to reconfigure), also potentially breaking other applications that take for granted that a tab character aligns to 8.

I see. I'm unaffected by this problem in my editor. Also, I am able to (and do) use a mouse most of the time.

Thanks for clarifying!

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 spaces rather than foolishly inserting a TAB and indenting by the standard 8. Other editors like Sublime Text stupidly insert a TAB and expect you to muck with how TABs are rendered in order to indent correctly.

Since many people don't understand that distinction, they map TAB to 4 columns which is incompatible with most formatters (including all printers and HTML). Switching to spaces is the only solution which really fixes this.

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.

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

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.

I prefer not to have to juggle invisible characters when editing plain text.

Tabs are visible in my editor. And so are the spaces at the end of a line it's sweet: :set listchars=tab:\|·,trail:·

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.

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.

Just add

    "translate_tabs_to_spaces": true

to your Preferences.sublime-settings to have spaces instead of tabs in Sublime Text.

That doesn't work if I'm editing a TABs-Are-8 file and still want to be able to indent by 4.

You need to use spaces for alignment, so indenting with tabs and aligning stuff (in the way suggested by PEP8[0]) is impossible without mixing tabs and spaces.

[0]: http://www.python.org/dev/peps/pep-0008/#maximum-line-length

If you read carefully, you'll see that you don't actually _need_ to align, you can always indent it further

In fact, I always found space-alignment cumbersome and sometimes ugly... always indenting with tabs was thus perfectly consistent

But that's the past, now :)

YMMV but I always felt the spirit of that rule was "Don't mix tabs and spaces for indenting (ie. where it matters to the interpreter)".

Indeed, a quick test with python -tt shows that the tab-indent/space-align method does not throw an error, while using tabs and spaces to indent does.

Reply on news.ycombinator.com