classification
Title: indentation in IDLE 2.6 different from IDLE 2.5, 2.4 or vim
Type: behavior Stage:
Components: IDLE Versions: Python 3.0, Python 3.1, Python 2.7, Python 2.6
process
Status: closed Resolution: accepted
Dependencies: Superseder:
Assigned To: kbk Nosy List: gpolo, kbk, rhettinger, sy12
Priority: high Keywords: 26backport, patch

Created on 2009-02-02 14:36 by sy12, last changed 2009-04-25 23:28 by kbk. This issue is now closed.

Files
File name Uploaded Description Edit
bug.py sy12, 2009-02-02 14:36
fix_5129.diff gpolo, 2009-03-24 03:32
Messages (10)
msg80941 - (view) Author: (sy12) Date: 2009-02-02 14:36
platform: Windows XP

In a file (cf attached file) with mixed tabs and spaces, the line
following "else:" appears at the same level than "else:", while the file
probably still works with Python 2.6. At least, IDLE 2.5 or IDLE 2.4 or
vim don't have this problem.
msg80964 - (view) Author: (sy12) Date: 2009-02-02 17:21
IDLE's "untabify" feature (required by IDLE 2.6 when running from IDLE)
seems to do the job correctly but this function doesn't inspire trust
and might damage the code, because IDLE 2.6 is not able to correctly
display mixed spaces and tabs (maybe for a reason linked to python 3 but
I didn't find it in the logs, so maybe it's just a bug) and because of
the default value given by the dialog, quite frightening: 4 spaces for a
tab, instead of 8. By giving 8 the problem seems to be solved, even for
IDLE 2.6.

Maybe IDLE 2.6 is assuming by default that a tab is 4 spaces?
msg80975 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2009-02-02 18:24
I don't see a problem with Untabify.  IDLE cannot know how big you
intended your tabs to be, so it presents a dialog asking you.  That
seems reasonable to me.

In most cases, the default is pretty good -- it attempts to infer the
tab width by finding the first manual indentation using spaces:

   'if:\n  pass\nif:\n\tpass\n'   --> guesses a two space indent

What differences are you seeing between 2.5 and 2.6?  Is it the initial
display is different, is the untabify default different, or what?
msg80990 - (view) Author: (sy12) Date: 2009-02-02 20:11
The problem appeared in the initial display, with a file similar to bug.py.

Here is how to reproduce it:
1. open the bug.py file with IDLE 2.5 (or with Firefox from the
bugs.python.org website): the display shows the file the way the
compiler will (probably) see it;
2. open the bug.py file with IDLE 2.6: the line 7 (just after "else:")
is displayed differently.

Summary: IDLE 2.6 doesn't display the indentation that the compiler will
see.

-----------------------------------------
About the secondary problem with Untabify (discovered when trying to
solve the display problem without having to reinstall Python 2.5):

Actually, Untabify is more a solution than a problem, except maybe that
the only safe value is 8 spaces for a tabulation. Using a different
value on legacy code (old code without tests) might add subtle bugs.

According to the Python Language Reference:
"First, tabs are replaced (from left to right) by one to eight spaces
such that the total number of characters up to and including the
replacement is a multiple of eight (this is intended to be the same rule
as used by Unix)."
-----------------------------------------
msg84051 - (view) Author: Guilherme Polo (gpolo) * (Python committer) Date: 2009-03-24 02:25
I just tried it here under Windows XP (using python 2.6.1 from
python.org) and the untabify dialog showed up with 8 as the default
number of columns per tab (although there are at least two bugs with
this dialog: i) I clicked on cancel but it still untabified the region;
ii) The window shows at a place before it is properly configured and
then shows up in its final place).

Also, from what I remember, IDLE always assume that a tab takes 8
columns and never modifies it. But the untabify dialog doesn't use this
fixed value, so it will vary depending on the code you run it (just
remembering again, with your bug.py it did show 8 here).

As for the real problem mentioned -- the differences in the visual,
regarding the indentation, between 2.5 and 2.6, I can't comment yet.
msg84052 - (view) Author: Guilherme Polo (gpolo) * (Python committer) Date: 2009-03-24 02:34
It turns out that the problem is not in differences between IDLE in 2.5
and the one in 2.6, instead it is caused by the usage of Tk 8.5 by IDLE
2.6 (included in the Windows package). Changing to Tk 8.4, IDLE 2.6
displays in the same way as 2.5 (tested on Linux where I also had the
difference in visual).
msg84054 - (view) Author: Guilherme Polo (gpolo) * (Python committer) Date: 2009-03-24 02:58
You do not need IDLE to reproduce the problem:

import Tkinter

text = Tkinter.Text()
text.pack()
text.insert('1.0',
        'class C:\n\tdef m(self, c):\n                '
        'if c:\n                        c = False\n'
        '\t\t\tc = False\n                else:\n        '
        '\t\tc = True\n\t\tc = True\n')
text.mainloop()

Then run it with tk 8.4 and tk 8.5.
msg84057 - (view) Author: Guilherme Polo (gpolo) * (Python committer) Date: 2009-03-24 03:32
Patch attached, if someone can create a test for it then that would be
very good.
msg84576 - (view) Author: Kurt B. Kaiser (kbk) * (Python committer) Date: 2009-03-30 16:32
r70723. Thanks for the patch!
Backport to 2.6.2....
msg86571 - (view) Author: Kurt B. Kaiser (kbk) * (Python committer) Date: 2009-04-25 23:28
Backported to release26-maint: r71911
Also issue for 3.0.1, which distributes Tk8.5 on Windows.
Was forwardported to py3k: r71189
Backported to release30-maint: r71944
History
Date User Action Args
2009-04-25 23:28:53kbksetstatus: pending -> closed

messages: + msg86571
versions: + Python 3.0
2009-03-30 16:35:30kbksetstatus: open -> pending
2009-03-30 16:32:41kbksetkeywords: + 26backport
resolution: accepted
messages: + msg84576

versions: + Python 3.1, Python 2.7
2009-03-24 14:58:25gpolosetmessages: + msg80941
2009-03-24 14:55:42gpolosetmessages: - msg80941
2009-03-24 03:32:31gpolosetfiles: + fix_5129.diff
keywords: + patch
messages: + msg84057
2009-03-24 02:58:03gpolosetmessages: + msg84054
2009-03-24 02:34:50gpolosetmessages: + msg84052
2009-03-24 02:25:02gpolosetnosy: + gpolo
messages: + msg84051
2009-02-02 21:57:13rhettingersetpriority: high
assignee: kbk
nosy: + kbk
2009-02-02 20:11:55sy12setmessages: + msg80990
2009-02-02 18:24:25rhettingersetnosy: + rhettinger
messages: + msg80975
2009-02-02 17:21:20sy12setmessages: + msg80964
2009-02-02 14:36:14sy12create