indents final final algorithm

"Mark Hahn" <[email protected]> Sat, 3 Apr 2004 12:56:47 -0800
Newsgroups gmane.comp.lang.prothon.devel,gmane.comp.lang.prothon.user
Message-ID <000f01c419be$3172e330$d701a8c0@MarkVaio>
The python lists had a good idea for one final tweak on the indent scheme.
I was going to bounce it off the Prothon lists before putting it in the
weekly release, but the Prothon servers are down today so I decided to use
my BDFL powers to go ahead and include the change.

Instead of making the rule that you must use tabs or spaces only per file,
it is going to be per block.  In other words I'm clearing the flag that
tells whether you are using tabs or spaces every time the indentation level
goes to zero.

This finally addresses the real problem head-on.  That is the problem of
indents not lining up because of mixed tabs and spaces and different people
defining tabs to be different widths.  With this final algorithm, you can
change the tab widths all you want and indent levels are guaranteed to line
up in all cases.

I wonder why we had to go through all these arguments and discussions when
in hindsight, this final solution seems so obvious.  There was a problem of
mixed tabs and spaces causing an indentation line-up problem that has been
known in Python for a long time, and yet it took all this collective pain to
come to what now seems like an obvious solution.  Oh well, I guess we aren't
as smart as we think we are.

Indentation rules:

1) You must use only tabs or only spaces for indents in any one indentation
block. You cannot mix tabs and spaces in a block.  A block is defined as a
group of consecutive indented lines.  Non-indented lines seperate blocks.

2) Each indent level can have any number of characters more than the
previous level, whether you are using tabs or spaces.  If you drop back to
the left to dedent, and your column position does not match any level above,
you will get a lexer error.

3) If you  increase the indentation level above the previous line by even
one character, and that previous line does not end in a colon, then the new
line will be considered a continuation of the previous line.

4) If a line contains an active (not quoted or commented)  (, {, or [
without a matching end character, then the following line is always a
continuation, no matter what that following line contains.

5) There is still support for using the trailing backslash ( \ ) to indicate
that the next line is a continuation.  This may be removed in the future if
everyone agrees to do so.

6) A continuation line is effectively added to the end of the previous line
so any line following a continuation line uses the last non-continuation
line for the "previous line" in all the rules above.