[Python-bugs-list] [ python-Bugs-587239 ] python-mode and nested indents

[noreply@sourceforge.net]

Bugs item #587239, was opened at 2002-07-26 20:56
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=587239&group_id=5470

Category: Demos and Tools
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew Koenig (arkoenig)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: python-mode and nested indents

Initial Comment:
Using Python-mode 4.6 and GNU emacs 21.2.2, I enter the
following:

if x < 0:
    for i in range(100):
        print i
else:
    print "x is negative"

If I now put the cursor on the "else:" line and hit
tab, it erroneously changes the indentation to line the
"else" up with the "for" above it.


----------------------------------------------------------------------

>Comment By: Andrew Koenig (arkoenig)
Date: 2002-07-26 22:14

Message:
Logged In: YES 
user_id=418174

If you really believe that hitting tab means that the block
structure isn't what you intended, then you should also
believe that hitting tab repeatedly on a line that can
legally be indented in exactly two different ways
(presumably with different meanings) should cycle between
the meanings.  Which it doesn't in this case.

I am willing to accept that hitting tab should generate the
maximum legal indent, which would mean that the behavior I
described with "else:" isn't a bug.  I do think, though,
that generating an illegal indent should be considered a
bug.  I also think that for most cases, lining up an "else"
with the nearest preceding "if" or "elif" rather than the
nearest preceding "for" or "while" is less surprising,
though I'll admit that's a matter of taste.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-07-26 22:05

Message:
Logged In: YES 
user_id=31435

I agree that the second one (elif) may be considered a 
bug.  Afraid I can't agree aboiut the first reason, though:  of 
course hitting tab in pymode can change the meaning.  
When you've got

if whatever:
->x
y

and hit tab when on the line containing y, it assumes you're 
hitting tab for a reason, not just to make trouble <wink>.

I believe there's a discussion about this in the long form of 
the pymode help.  Since pymod can't *know* the block 
structure you intend, it does its best to guess, and hitting 
a "guess the block structure I intended" key is taken as 
meaning, for a start, that the block structure on the current 
line isn't what you intended (else why would have hit the 
key?  as a Python programmer, you should already know 
this isn't C mode <wink>).

----------------------------------------------------------------------

Comment By: Andrew Koenig (arkoenig)
Date: 2002-07-26 21:49

Message:
Logged In: YES 
user_id=418174

Frankly, I hadn't thought of that possibility!

However, I still consider the behavior a bug, for two
reasons:  (1) I can type something that's syntactically
valid, hit tab, and have it change the meaning of what I
typed, and (2) It changes the indentation in the same way if
I say "elif:" instead of "else:", even though that change is
not syntactically valid.  That is (using -> to indicate a
tab):

if x < 0:
->for i in range(100):
->->print i
elif x > 0:
->print x

Again, hitting tab on the "elif" line will indent the "elif"
to line up with the "for", even though the result is
syntactically invalid.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-07-26 21:14

Message:
Logged In: YES 
user_id=31435

Andrew, why is that erroneous?  Loops in Python have 
(optional) "else:" clauses too.  There's no way for pymode to 
guess whether you intended the else to go with the if or the 
for.  I expect it looks backward for the closest-preceding 
construct the else-statement could "belong to", and finds 
the for-loop first.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=587239&group_id=5470