Deprecate tabs for indenting (was Re: Indenting with tabs vs spaces)

[Paul Boddie]

Steve Lamb <grey at despair.dmiyu.org> wrote in message news:<slrna0mh0t.ecm.grey at teleute.dmiyu.org>...
> On Sun, 2 Dec 2001 20:13:37 -0600, Jeff Hinrichs <jlh at home.com> wrote:
> > my 0.02$US:
> > Actually, spaces are the problems not tabs.  A tab is a tab, where is
> > indenting by spaces....hmm.
> 
>     No, a tab isn't a tab.

It's hard to know what you're getting at here. Is this the ultimate
form of denial? :-)

The Tab key (or whatever symbol is used on your keyboard to denote it)
is commonly used to move the cursor to a particular location, whether
it be the next field in a form, or whether it be to a particular
horizontal position in a human-readable textual document. On my
keyboard, the symbol used is an arrow pointing to a vertical line
which indicates a well-defined location.

In neither of the two examples given above does use of the Tab key
correspond to any number of spaces - one doesn't move 8 spaces to the
next field in a form, nor does one set a tabstop in a word processor
to 4cm under the illusion that 4cm now means any particular number of
spaces.

> > You should be able to configure your editor to display tabs in a width that
> > is to your liking WITHOUT mucking with the data.
> 
>     As you just said, "You should be able to configure your editor to display
> tabs..."  Oh, so a tab isn't a tab.  I like indention of 4 so my tab is 4
> spaces.  You like 8 so yours is 8 spaces.  A tab is not a tab.  A tab is a
> collection of spaces, visually.

A tab causes movement to the next defined horizontal position on the
current line. Text editors often define these positions at intervals
which are a number of spaces apart in the current font, but that does
not mean that they are in any way equivalent to spaces. Moreover,
depending on where the cursor is when the Tab key is pressed, the
horizontal movement can vary depending on the distance between the
current cursor position and the next tabstop.

>     Now, if you had read my post you would have seen where your whole "a tab
> is a tab" bubbub breaks down.  Here it is AGAIN since you missed it the first
> time.
> 
> some_dict = {'Jane':{'Age':'21', 'Dept':'0001', 'Ext':'1234'},
>              'John':{'Age':'22', 'Dept':'0010', 'Ext':'5678'},
>              'Jeff':{'Age':'23', 'Dept':'0100', 'Ext':'9009'},
>              'Jody':{'Age':'24', 'Dept':'1000', 'Ext':'8765'},
>              'Jeny':{'Age':'25', 'Dept':'0110', 'Ext':'4321'}
>             }
> 
>     With spaces that always comes out the same.  With tabs set to different
> lengths you get different results.  The only constant when it comes to
> indention is a space.  A space is a space.  A tab is not constant and
> therefore should NOT be used for indention.  Ever.

Indentation isn't at all important with respect to the correct
interpretation of the above statement (which is the real issue here),
but I've long suspected that you don't have a real argument to bring
to the table.

>     Indention isn't about preference, it is about making the code readable.
> And as the above example shows, readable code could be rendered unreadable by
> tab "preferences".

You're wasting your time making code "art" just as I could be wasting
my time explaining to you what a tab is. In short, we're both wasting
our time.

Paul