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.

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?

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?

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)."
-----------------------------------------

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.

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).

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.

Patch attached, if someone can create a test for it then that would be
very good.

r70723. Thanks for the patch!
Backport to 2.6.2....

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