© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
e3ace39
(Get the code!)
(migrated from python project, bug #587239)
Original submission:
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.
Followup comments:
Date: 2002-07-26 17:40
Sender: tim_one
Logged In: YES
user_id=31435
It's up to Barry to decide (and I assigned the report
to
him). I'll only add that the behavior does appear to be
as
documented:
"""
The \\[indent-
and-
indent] keys try to suggest plausible indentation,
based on
the indentation of preceding statements.
[example snipped]
Python-mode cannot know whether that's what you
intended, or whether
\tif a > 0:
\t c = d
\t_
was your intent. In general, Python-mode either
reproduces the indentation of the (closest code or
indenting-comment) preceding statement, or adds an
extra
py-indent-offset blanks if the preceding statement
has `:' as
its last significant (non-whitespace and non-
comment)
character. If the suggested indentation is too much,
use
\\[py-electric-
""
That seems (to me) easy to remember and to live
with.
Date: 2002-07-26 17:14
Sender: arkoenig
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.
Date: 2002-07-26 17:05
Sender: tim_one
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>).
Date: 2002-07-26 16:49
Sender: arkoenig
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.
Date: 2002-07-26 16:14
Sender: tim_one
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.
[http://