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

[Huaiyu Zhu]

On Mon, 03 Dec 2001 20:51:34 GMT, Erik de Castro Lopo <nospam at mega-nerd.com>
wrote: 
>
>However, the people who like me prefer using tabs (and nothing but tabs) for 
>indentation need to speak up.

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.

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.

When a tab key is hit, the tab-character editor enters the ascii tab
character in the file.  It also displays the character in a way that is
often configurable.  The character is persistent (saving to file, sending to
someone else) and meaningful to Python, while the display is only effective
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.

In contrast, when a tab key is hit, the tab-display editor would translate
that into a sequence of other characters, usually a given number of spaces,
that produces the same display effect.  This display effect is persistent on
file and effective for Python.  The fact that they were entered using the
tab key is not recorded anywhere, probably not even in the current editing
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.

Many editors can be configured to behave either way (some even do additional
magic with the tab key).  But there might be crippled editors that only
allow one style.  That might be what's behind the claims that "it is not a
matter of personal preference" and "you can not separate style from
content".

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
display setting would leak to other programmers?  I have limited experience
with MS native editors.  So I'm not sure if this is the case.  If it is
indeed the case, it can well explain why they do not see there being a
choice, let alone to consider which choice is better.

So we talk about the distinction between logical and visual formats, about
tab the character and tab the position.  But if the editor never allowed
such distinctions, none of these make much sense, and the tab-as-indent
argument might just sound as rhetoric to them.  To users of such editors,
"indent" always means visual indent; the Python block structure is only a
secondary effect.

The all-tab model we are talking about is like this (scheme A)

            A's editor        file exchange         B's editor
    visual <---------- tab <-----------------> tab -----------> visual
                       |                       |
                python |                       | python
                       V                       V
                     indent                  indent

But many of the arguments against it lead me to believe that non-tabbers
think we are talking about something like this (scheme B)

           A's editor           file exchange           B's editor
      tab <----------> space <-----------------> space <----------> tab
       |                                                             |
python |                                                             | python
       V                                                             V
     indent                                                        indent

while their preferred one is (scheme C)

           A's editor           file exchange           B's editor
      tab <----------> space <-----------------> space <----------> tab
                         |                         |
                  python |                         | python
                         V                         V
                       indent                    indent

If the only practical choice is between scheme B and scheme C, it is quite
understandable why C is preferred to B.  Indeed, in that case, there is very
little advantage in using tab at all.

If indeed one side is debating between A and C while the other side is
debating between B and C, and they thought they are in the same debate, that
could explain why the debate continues.  

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?

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


Huaiyu


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.