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

[Carel Fellinger]

Huaiyu Zhu <huaiyu at gauss.almadan.ibm.com> wrote:

> It appears that both sides have already spoken enough and the issue is quite
> clear.  So I have been wondering why it continues like a religious war.

Nice someone still tries to get this discussion to halt:)

> It occurred to me that the reason might be that there are two different kinds
> of editor behaviors concerning tab, and that users of one kind of editor do
> not really understand what the other side is talking about.  I'll call these
> editor styles the tab-character editor and the tab-display editor.

And a nice try, but...

...in the tab-character editor argument
> in the particular editor session.  The display usually takes the size of a
> given number of spaces, but it really behaves like a single character to the
> arrow keys, delete and backspace keys and to cut and paste.

alas, cut&past on an X display will not see those tabs, but only the
spaces used to represent them at the moment:(

...and in the tab-display editor argument
> session.  For example, the arrow keys will not move over tab as a single
> character, and the delete key need to be hit more than once to delete it.

fortunately some editors are smart enough to recognize an indentation
and allow single delete's to delete one indentation level worth of
spaces.  And using the cursor keys is frowned upon by those using word
or sentence jumping keys:)

...
> So I'd suggest the tab advocates to consider the other side's view.  What if
> their editors never allow this to be a _personal_ preference?  What if any

it's not only the editor, but actually the whole environment they work in.

...nice scheme's snipped
> So my question is this: Is it true that for some people there is never a
> choice between all-tab and all-space, only a choice between mix-tab-space
> and all-space?

yep, for all of us that use X's crippled cut&paste

> If this so, whatever the merits of all-tab, the final result of the debate
> might just be dictated by the simple fact "scheme A is not available as a
> practical choice for some users because of the editors they use".

So because of X's limited cut and paste capabilities the whole
discussion is over, and we finally agree that tabs are out:)


> PS. Space is better for visual formating, such as lining up multiline (), []
> and {}, but these are not syntactical indentation concerning Python.  I did
> not use tab for the above diagrams as it is visual formating.

PS. I once worked on a system where all leading spaces and tabs were
replaced by a single byte denoting the total number of leading spaces
by the file system it self.  Okee, make didn't work there, but apart
from that the system was a nice and refreshing experience back then.

-- 
groetjes, carel