I'm using python 3.0 final which was released on December the 3th.
I also have python 2.5 installed.

2 bugs in python3 IDLE which might be related (but don't have to)

1.
The Python3 IDLE sometimes suddenly closes.
It always happens when I'm using it for a while, then press the shift +
home or end key and then it just disappears and my unsaved work is lost.
It really completely exits without an error and I also don't see it on
the background.

I'm unable to reproduce the error. But it usually happens when I have
hold down shift and press the home key.

2.
When I have some code then scroll down the code, then hold down shift
and press up a few times, then press home the selected code completely
switches.
Instead some code above the cursor suddenly gets selected.

The reason I think both are related is because both involve shift + home
key.

Both of the bugs have never happened in the IDLE 1.2.1 which was part of
python 2.5.2
I think

I have found a way to reproduce this error:

\\\\
Open the idle
Hold down shift:
   Press up 3 times
   Hold [fn] (on laptop)
   Press the home key
Idle closes for no reason
////

Any help?

I can't reproduce this with py3k on linux, but I do get a traceback in
the terminal used to launch idle:

Exception in Tkinter callback
Traceback (most recent call last):
  File "/home/ajaksu/py3k/Lib/tkinter/__init__.py", line 1399, in __call__
    return self.func(*args)
  File "/home/ajaksu/py3k/Lib/idlelib/MultiCall.py", line 165, in handler
    r = l[i](event)
  File "/home/ajaksu/py3k/Lib/idlelib/EditorWindow.py", line 315, in
home_callback
    if self.text.compare(first,">",last):
  File "/home/ajaksu/py3k/Lib/tkinter/__init__.py", line 2844, in compare
    self._w, 'compare', index1, op, index2))
_tkinter.TclError: expected boolean value but got ""

That only happens sometimes happens, pressing home while holding shift
down does nothing but print the traceback. Else, pressing 'home' holding
shift alternates: start of line, start of indented block.

Somelauw: Are you running Windows, Linux, other?

The bug may be related to a special key with no binding: no mapping in 
the kernel, in your Windows/Xorg configuration or in python Tk module. 
The key is maybe not shift+home but strange combinaison related to 
your laptop special keys.

It would be nice if the OP could confirm that the bug described by
Daniel is the same one as he gets. I can reproduce it on linux on all
the versions I marked, but didn't have time to fix it yet.

To the OP: If you are running Windows, try starting IDLE on the prompt,
reproduce the error, and check if anything is printed back to you.

I'm using windows XP home edition SP2

Yes, my error message is similair to the one of ajaksu2 when I run the 
IDLE on the commandline. (when opened from windows explorer, it justs 
closes)
Also problem 2 is similair.

Patch against trunk attached.
It fixes only the first problem reported, and I can't reproduce the
second one.

I have experienced similar problems in Python 2.6.1 on Windows, and
found them to be due to Tk 8.5. I posted my findings here:

http://mail.python.org/pipermail/idle-dev/2009-January/002738.html

In summary, Tk 8.5 changed the name of the "anchor" mark to be unique to
each Text widget. The code to make the home key toggle between column 0
and the start of the text tries to make use of the "anchor" mark and
gets confused.

In the email I proposed a simple fix which I'm testing out right now.
Should I attach it as a patch?

Another complication. On Windows, this line doesn't do what it claims:

if (event.state & 12) != 0 and event.keysym == "Home":
    # state&1==shift, state&4==control, state&8==alt
    return # <Modifier-Home>; fall back to class binding

The comment says state&8==alt, but this is wrong. state&8==mod1, and on
Windows Tk defines mod1 to be num-lock. So if you have num-lock on,
home_callback will always fall back to the standard binding.

See the Tk source:
xlib/X11/X.h   defines Mod1Mask
win/tkWinX.c   maps VK_NUMLOCK to Mod1Mask

Just got a chance to test this on a Windows desktop with a proper 
keyboard. (My laptop does weird things with num-lock and scroll-lock.) I 
got it to crash once, but I have no idea what was special about that 
time. Otherwise I can reproduce the exception traceback printed to the 
console, with the following steps:

1) Start IDLE from the console, e.g.:
    python c:\python26\Lib\idlelib\idle.py
2) Make sure num-lock is turned OFF.
3) Enter a few characters, e.g:
    rhubarb
4) Press shift+left to create a selection of at least one character.
5) Press shift+home. The stack trace appears in the console:

Exception in Tkinter callback
Traceback (most recent call last):
  File "C:\Python26\lib\lib-tk\Tkinter.py", line 1410, in __call__
    return self.func(*args)
  File "C:\Python26\lib\idlelib\MultiCall.py", line 150, in handler
    r = l[i](event)
  File "C:\Python26\lib\idlelib\EditorWindow.py", line 333, in 
home_callback
    if self.text.compare(first,">",last):
  File "C:\Python26\lib\lib-tk\Tkinter.py", line 2858, in compare
    self._w, 'compare', index1, op, index2))
TclError: expected boolean value but got ""

This is consistent with my understanding that Tk 8.5 does not use a mark 
named "anchor" to indicate the selection anchor. I have written a patch 
that directly calls "tk::TextKeySelect" instead of trying to duplicate 
its behaviour using the "anchor" mark. I'm not terribly confident with 
using diff and patch, so please let me know if I've done it wrong. I did 
use -u.

> Weeble added the comment:
>
> In summary, Tk 8.5 changed the name of the "anchor" mark to be unique to
> each Text widget. The code to make the home key toggle between column 0
> and the start of the text tries to make use of the "anchor" mark and
> gets confused.
>
> In the email I proposed a simple fix which I'm testing out right now.
> Should I attach it as a patch?
>

I see your simple fix depends on a unsupported proc provided by tk,
how good is to depend on it ?
And I don't think that is backwards compatible till tk 8.2, is it ?

Well, the status quo depends on an unsupported field - "anchor". As far
as I can tell, the only other option that allows any customisation of
cursor behaviour is to re-implement the entire selection system from the
ground up. Would it be acceptable to detect the Tk version and change
strategy accordingly?

I don't know how far back this would work: I've tested it with Tk 8.5
and 8.4.

I'll ask on comp.lang.tcl and see what they recommend fpr customising
the behaviour of a text widget.

Thanks for looking over this.

I posted a question on comp.lang.tcl here:

http://groups.google.com/group/comp.lang.tcl/browse_thread/thread/aab17806f6fa837f#

By the way, which versions of Tk must Python support? Where do I find
out things like that?

> Weeble  added the comment:
>
> Well, the status quo depends on an unsupported field - "anchor".

Better not repeat the mistake then ?

> As far
> as I can tell, the only other option that allows any customisation of
> cursor behaviour is to re-implement the entire selection system from the
> ground up. Would it be acceptable to detect the Tk version and change
> strategy accordingly?
>

IDLE already reimplements several things, which were useful back then
when it wasn't reimplementing -- just adding functionality. If the
only correct solution is really to reimplement the selection, then it
would be better to do it anyway, but I don't think it is.

I'm interested in knowing how many interactive shells implement this
same behaviour, or if there are that many I would like at least some
examples. I'm unsure about the usefulness of the current functionality
(supposing it was working as intended).

> I don't know how far back this would work: I've tested it with Tk 8.5
> and 8.4.
>

All versions of 8.4 ? I've seen complaints about early releases of tk
8.4 and the use of the unsupported function.

You're right: we should find a solution that's safe and supported.

I *think* the primary reason for overriding the home key behaviour was 
not for the interactive shell, but to make it easier to edit code. Most 
programmer's editors that do automatic indentation also let you use home 
to move to the beginning of the text on a line, rather than the absolute 
beginning of the line. I couldn't say for sure though: I'm new here.

I've proposed some changes to the ctrl-left, ctrl-right behaviour on 
idle-dev that would also require custom handling of selection behaviour. 
If it were to be decided that reimplementing the selection-handling was 
worthwhile I would be willing to work on such a patch to redo the 
selection-handling using only supported Tk features, but I get the 
impression I'd need lots of help to get it tested with every possible 
version of Tcl/Tk.

> Weeble added the comment:
>
> I *think* the primary reason for overriding the home key behaviour was
> not for the interactive shell, but to make it easier to edit code. Most
> programmer's editors that do automatic indentation also let you use home
> to move to the beginning of the text on a line, rather than the absolute
> beginning of the line.
>

Yes, but IDLE goes beyond that and adds some weird behaviour.
Suppose you have this line in IDLE:

>>> xxxx

Why would you want to go at the absolute beginning there ? That is
what happens when you press home twice.
Then there is the other case, the reason for the current home code:

   y, ...

Pressing home twice while on the second line toggles between the
absolute start of that line and one position before y, this is the
behaviour that I haven't seen used anywhere else (but it is not like I
have used many GUI shells). If it is used everywhere else I haven't
looked at then this might be good because people are accustomed to,
otherwise it is just a feature that IDLE has for no reason.

> I've proposed some changes to the ctrl-left, ctrl-right behaviour on
> idle-dev that would also require custom handling of selection behaviour.

I'm subscribed to idle-dev but I assume I don't read it at all.

> If it were to be decided that reimplementing the selection-handling was
> worthwhile I would be willing to work on such a patch to redo the
> selection-handling using only supported Tk features, but I get the
> impression I'd need lots of help to get it tested with every possible
> version of Tcl/Tk.
>

Before start writing new code I suggest to check how many IDLE forks
exist, and check if any of them has this fixed. It would be good to
start writing tests for idlelib too.
Testing with every possible version of Tcl/Tk is not going to work,
the minimal possible is 8.2 as it is what _tkinter supports. But I
suspect most people are using tk 8.4 (and then there are a lot of
minor releases), some tk 8.5 and very few using other versions.
The externally maintained tk versions are 8.4.12, 8.4.16, 8.4.18.1 and
8.5.2.0 so we could target these versions.

I can't see any useful reason to go to the absolute start of the line in 
the interactive shell. However, it does make sense in the source editor, 
and it is consistent with, for example, Visual Studio. The first use-
case off the top of my head is when you want to copy a block of code and 
not lose the relative indentation of the first line. You press home-
twice to go to the absolute start of line and select from there. It's 
also the only quick way in IDLE to be sure that the text widget is 
scrolled all the way to the left, since there's no horizontal scrollbar. 
(Any idea why that is? I assumed it's to discourage long lines, but I 
don't know.)

The proposal I refer to in IDLE-dev is this:
    http://mail.python.org/pipermail/idle-dev/2009-January/002742.html

I only mention it because it demonstrates another reason why we might 
want to override the default selection/navigation mechanics.

> It's
> also the only quick way in IDLE to be sure that the text widget is
> scrolled all the way to the left, since there's no horizontal scrollbar.
> (Any idea why that is? I assumed it's to discourage long lines, but I
> don't know.)

The shell is configured to wrap lines if they get too long, but you
will notice that pressing 'end' doesn't really get you to the end of
line.
It should be easier to not wrap there too and add a horizontal
scrollbar (if needed) to all text widgets used by idle.

Thanks for the research on the home key toggle.  Let's take that
to issue3851, it seems it's different from the rest of this
issue.

Can this bug be closed?

New changeset c4d355363114 by Kurt B. Kaiser in branch '3.1':
<Home> toggle failing on Tk 8.5, causing IDLE exits. Issue #4676
http://hg.python.org/cpython/rev/c4d355363114

Fixed in 2.7 and forward ported.