homepage

IDLE (for Python 3.2) fails to save using the ctrl-s keyboard shortcut when caps-lock is enabled, and instead only saves when ctrl-shift-s is pressed.
When caps-lock is disabled, all shortcuts work normally.

(The message I deleted was a duplicate of the original).
Verified with 3.2.0 on WinXP (Jacob, I/O issues, including keyboard, especially need system specified. What is yours? If Windows, this might be Windows-specific.)
With CAPS LOCK on, Cntl-N, Cntl-O, Cntl-P, Alt-M, Alt-C work.
Cntl-S, Cntl-Shift-S, Alt-Shift-S, Cntl-Q do not.
(All of above from File menu). So behavior is variable.

I'm running Windows 7 Home Premium 64-bit, on an Alienware M17x (a laptop) using the built-in keyboard.
It's definitely possible that the problem is Windows-specific; perhaps it has to do with the fact that when caps lock is on the shift modifier seems to invert the case back to lowercase; although I don't know how it would affect it in that way.

I can confirm this issue on Linux.
This issue is caused by not explicitly binding <Control-Key-S> to <<save-window>> in config-keys.def (and in configHandler.py's GetCoreKeys.) Presently, only <Control-key-s> binds to <<save-window>>.
Should all the lowercase bindings without uppercase bindings be changed, or should only a few be changed?

I would like to see them all changed.

I agree; lets be consistently lenient.

Attached is a patch to fix the caps-lock issue with Windows key bindings in config-keys.def.

Changes look complete and correct as far as I can tell, except that I have some confusion about the relation of Shift and CapsLock key. For instance, Control-C and Control-Shift-C (using the key labels) both interrupt a loop whether or not CapsLock is on. In all, 4 combinations work even though only 2 are listed.
 interrupt-execution=<Control-Key-c> <Control-Key-C>
However, this pair of specifications
+save-window-as-file=<Control-Shift-Key-S> <Control-Shift-Key-s>
+save-window=<Control-Key-s> <Control-Key-S>
only makes sense to me if 's' and 'S' refer to the 'S' key without and with CapLock on as using Shift is meant to give a different meaning. It appears to split the 4 combinations into 2 pairs that do different things.

I know that Tk has individual states for whether or not a key is pressed with Caps Lock or Shift or other modifiers, so maybe there is a way to have the shortcuts ignore Caps Lock entirely.
More info: http://stackoverflow.com/questions/665502/status-of-shift-and-caps-lock-in-python 

See also "Modifier Keys" on the Tk Wiki:
 http://wiki.tcl.tk/28331
There are both deliberate and accidental platform-specific behavior differences among Tk implementations.

Reading the Tk Wiki page, it appears that Shift undoes ShiftLock except on Mac, where it does nothing. So there is effectively only ^a and ^A, etc.
Looking as the Get New Keys dialog, the Basic Key Binding Entry pane says "New keys .." plural, but as far as I can tell, only one new key can be entered. Moreover, Control-Key-a and Control-Shift-Key-A are possible, but not Control-Key-A. The latter is only possible with hand entry in the Advanced Key Binding Entry pane. This might be why some functions have a single key binding and some both. Perhaps the dialog should auto-augment Control-Key-x with Control-Key-X, where x is a lowercase letter.

New changeset 55fed3eae14b by Terry Jan Reedy in branch '2.7':
Issue #12387: Add missing upper(lower)case versions of default Windows key
http://hg.python.org/cpython/rev/55fed3eae14b
New changeset 25fd9aeeff91 by Terry Jan Reedy in branch '3.4':
Issue #12387: Add missing upper(lower)case versions of default Windows key
http://hg.python.org/cpython/rev/25fd9aeeff91 

I pushed Roger's patch so that the Windows section of config-keys.def is in a consistent state. However, this does not fix the problem for config-extensions.def or user versions of config-keys.def. A) The basic method of the key dialog does not allow entry of proper pairs. B) it is easy to forget to enter both versions when using the advanced method or editing a file directly.
So rather than develop a similar patch for the Unix block, which is always missing the uppercase version of key-bindings, our GSOC student will work on code to add the 'other' version when alpha key-bindings are read. If and when that works, the Unix block will work as is and the Windows block can have removed what will then become duplicates.

Attached patch is an attempt to fix the issue, based on msg220332.
With this patch, and with "IDLE Classic Unix" keybinding selected in IDLE,
actions like cut=<Control-Key-w>, redo=<Alt-Key-z> <Meta-Key-z>, and emac's style actions like open-new-window=<Control-Key-x><Control-Key-n>,
can be performed by just pressing the respective keys, irrespective of CAPS.
I would like to know if this patch is acceptable and whether it performs as expected on all platforms.