Issue587239
This issue tracker has been migrated to GitHub,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
Created on 2002-07-26 20:56 by arkoenig, last changed 2022-04-10 16:05 by admin. This issue is now closed.
Messages (7) | |||
---|---|---|---|
msg11735 - (view) | Author: Andrew Koenig (arkoenig) | Date: 2002-07-26 20:56 | |
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. |
|||
msg11736 - (view) | Author: Tim Peters (tim.peters) * | Date: 2002-07-26 21:14 | |
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. |
|||
msg11737 - (view) | Author: Andrew Koenig (arkoenig) | Date: 2002-07-26 21:49 | |
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. |
|||
msg11738 - (view) | Author: Tim Peters (tim.peters) * | Date: 2002-07-26 22:05 | |
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>). |
|||
msg11739 - (view) | Author: Andrew Koenig (arkoenig) | Date: 2002-07-26 22:14 | |
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. |
|||
msg11740 - (view) | Author: Tim Peters (tim.peters) * | Date: 2002-07-26 22:40 | |
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-for-tab-command] and \\[py-newline-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-backspace] to reduce it. "" That seems (to me) easy to remember and to live with. |
|||
msg11741 - (view) | Author: Skip Montanaro (skip.montanaro) * | Date: 2003-08-05 03:10 | |
Logged In: YES user_id=44345 Migrating to the new python-mode project. You can follow it here: https://sourceforge.net/tracker/ index.php?func=detail&aid=783235&group_id=86916&ati d=581349 |
History | |||
---|---|---|---|
Date | User | Action | Args |
2022-04-10 16:05:31 | admin | set | github: 36942 |
2002-07-26 20:56:05 | arkoenig | create |