covers point 1.1) "Pressing the Home key moves the cursor before the >>> prompt, which then makes the keyboard unresponsive."

This issues was fixed on Windows XP and Linux here http://bugs.python.org/issue3851


On Mac OS X the "home" key is control-A or function left arrow both have the same effect of moving the cursor left of prompt, which them makes the keyboard unresponsive.  I tested this with Python 3.4 and Python 2.7 on Mac OS X 10.8.4.

The reason for the observed behavior is that the built-in "IDLE Classic OSX" keyset, which is the default for OS X framework installs, has a different keybinding for "beginning-of-line".  See Lib/idlelib/config-key.def

[IDLE Classic OSX]
...
beginning-of-line = <Control-Key-Left>

I'm not sure why the decision was made to use this binding originally.  Unfortunately, on current OS X systems (with US keyboards at least) Control-Left is preemptively defined as the default system Mission Contol keyboard shortcut to "Move left a space" (e.g a desktop) so, by default, Tk (and, hence, IDLE) never sees it.  This can be seen by going to System Preferences -> Keyboard -> Keyboard Shortcuts -> Mission Control.  You can temporarily disable or change "Move left a space" and verify that then Control-L does perform as expected.  You can also verify that changing the IDLE keyset to "IDLE Classic Windows" redefines "beginning-of-line" to Control-A and Home.

There are a number of other problematic (non-functional) key bindings in the "IDLE Classic OSX" keyset depending on a number of factors: which Tk variant is in use (Cocoa Tk, Carbon Tk, X11 Tk), System Preferences keyboard shortcuts, possibly which keyboard and which system input method are in use.  For more info on some of the hard-to-fathom Tk differences see: http://wiki.tcl.tk/28331

After spending some time trying to understand how this all works or doesn't across the various Tk's, I am coming to the conclusion that we need to define a new set of default key bindings for OS X, one that generally avoids as much as possible the use of Command key and Option key accelerators, as these tend to be especially problematic either in Tk or with system conflicts, and, instead, use Fn keys for non-trivial accelerators.

er, Lib/idlelib/config-keys.def

Ned,
   Thanks for such a thorough comment this saved me lots of time now I don't have to dig so deeply into the problem.


"After spending some time trying to understand how this all works or doesn't across the various Tk's, I am coming to the conclusion that we need to define a new set of default key bindings for OS X, one that generally avoids as much as possible the use of Command key and Option key accelerators, as these tend to be especially problematic either in Tk or with system conflicts, and, instead, use Fn keys for non-trivial accelerators."

I like your purposed solution so I will look into trying to creat a new key binding for OS X.

IIRC the key bindings that are currently used on OSX basicly are partially based on the key bindings on "classic macos", and partially on using the CMD key instead of the ALT key.

It would be nice to have a clean set of key bindings for OSX that's based on the default key bindings for text widgets in Cocoa[1], with "logical" additions for IDLE-specific functionality.

It would also be nice if the key bindings for the various platforms could be kept in sync [2], that makes it easier to switch between platforms and is easier for educators. 

BTW. I don't think it using function keys for key bindings is necessarily a good idea on OSX. I'm pretty sure that the default keyboard settings on OSX require two key presses to use a function key on OSX laptops (the "fn" key and the actual function key) because the keys are used for their hardware control role without the "fn" key (that is, "fn" + "f8" is F8, while just "f8" is "play/pauze"). A number of function keys also have system-wide shortcuts (such as "show desktop"), I'm not sure if those shortcuts are still enabled by default on new installs.


[1] More or less documented here: <https://developer.apple.com/library/mac/#documentation/cocoa/Conceptual/EventOverview/TextDefaultsBindings/TextDefaultsBindings.html>, the file "/System/Library/Frameworks/AppKit.framework/Resources/StandardKeyBinding.dict" is a (binary) plist that contains the default keybinding.

[2] With the obvious differences, such as using the CMD key on OSX and ALT on Windows.

I think that those two requirements, i.e. (1) a set of key bindings compatible with standard Cocoa text key bindings and (2) a set of key bindings kept in sync across all IDLE platforms, would be desirable but probably unattainable.  A good next step would be for someone to make a table of the IDLE key bindings across the various keysets and platforms.  That would make it easier to make informed design decisions.

The "Classic Unix" keyset is quite different, with emacs-like multiple key strokes (like Ctrl-X Ctrl-N for New Window).  I wonder how widely it is used. For OS X, we have the aforementioned conflicts with system accelerators and with the Cocoa Tk we have already had to disable some common accelerators (like Cmd-M for Open Module..) because of conflicts with Cocoa Tk's builtin accelerators and the as-yet-unresolved Ctrl-5 and Ctrl-6 crashes (Issue16023).  The X11 situation is a mess with Option and Command being reversed and, yes, there are still users of Python with X11 Tk on OS X (for one, MacPorts provides it as the default option).  Perhaps the best solution for it is a separate OS X X11 keyset.

Re function keys: I created a new user account on a current OS X 10.8 (with a US keyboard on a MacBook Pro).  It seems that function keys are enabled by default.  This is controlled by a checkbox setting in the Keyboard panel of System Preferences.  With the box checked (the default), you have to press the fn modifier key to enable the hardware control functions.  Inspecting the default set of Keyboard Shortcuts in the panel, the only F(n) keys defined are F11, F12, Cmd-F5, Opt-Cmd-F5, and Ctrl-F1 through Ctrl-F7.  This conforms to the current OS X Human Interface Guidelines, Appendix A Keyboard Shortcuts, with the addition that the entire range F8 through F12 are marked as Apple reserved.  (Interestingly, the guidelines do not note that Ctrl-Left and Ctrl-Right are now used by Mission Control by default.)

That said, it would be great if IDLE could more closely follow the OS X Human Interface Guidelines, including the accessibility guidelines for Universal Access.  Of course, IDLE is very much dependent on Tk in these matters.  So trying to improve things will require a fair amount of research and experimentation with the Apple docs, Tk code, and IDLE itself.  It would be a good project for someone interested in practical User Experience design.

Additional references:

https://developer.apple.com/library/mac/#documentation/UserExperience/Conceptual/AppleHIGuidelines/KeyboardShortcuts/KeyboardShortcuts.html

https://developer.apple.com/library/mac/#documentation/Accessibility/Conceptual/AccessibilityMacOSX/OSXAXIntro/OSXAXintro.html

http://www.hcs.harvard.edu/~jrus/Site/System%20Bindings.html

> BTW. I don't think it using function keys for key bindings is 
> necessarily a good idea on OSX. I'm pretty sure that the default
> keyboard settings on OSX require two key presses to use a function
> key on OSX laptops

On Mac laptops, there is separate "fn" key that enables the function keys.  Users press "fn" and "F5" to run a script from IDLE.

I teach Python classes to Mac users and they are are no problems at all with the function keys.

Raymond: good to hear that using fn+F5 is not a problem for new users

I closed #17060 as a duplicate of this.  Roger Serwy there said
 "The .home_callback() in Lib/idlelib/EditorWindow.py contains the logic from #3851 for placing the cursor at the beginning of the prompt, but it requires that a key combination be bound to the beginning-of-line virtual event.

Should we append "<Key-Home> <Control-Key-a>" to the begining-of-line config in Lib/idlelib/config-keys.def ?"

Serhiy add IDLE Modern Unix a couple of years ago.  Something similar is still needed for macOS.

I closed #32761 about new macOS keyset, in favor of this one.  There is a bit more discussion there to consider.  I agree that a chart of <<key-event>> down side and keyset across top would be a good start.

I also closed #21359, which has more comment from Ned about bindings not working.