Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

IDLE save keyboard shortcut problem #56596

Open
jvanburen mannequin opened this issue Jun 22, 2011 · 14 comments
Open

IDLE save keyboard shortcut problem #56596

jvanburen mannequin opened this issue Jun 22, 2011 · 14 comments
Assignees
@terryjreedy
Labels
easy topic-IDLE type-bug An unexpected behavior, bug, or error

Comments

@jvanburen
Copy link
Mannequin

jvanburen mannequin commented Jun 22, 2011

BPO 12387
Nosy @rhettinger, @terryjreedy, @kbkaiser, @ned-deily, @serwy, @jvanburen, @ringof
PRs
  • gh-56596: IDLE keyboard shortcuts function irespective of caps-lock state #32245
    		•
    Files
  • windows_caps_lock.patch
  • keybinding-issue12387-v1.diff
    		•

    Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

    Show more details

    GitHub fields:

    assignee = 'https://github.com/terryjreedy'
closed_at = None
created_at = <Date 2011-06-22.17:59:58.252>
labels = ['easy', 'expert-IDLE', 'type-bug', '3.7']
title = 'IDLE save keyboard shortcut problem'
updated_at = <Date 2022-04-02.01:39:59.903>
user = 'https://github.com/jvanburen'

    bugs.python.org fields:

    activity = <Date 2022-04-02.01:39:59.903>
actor = 'dpg'
assignee = 'terry.reedy'
closed = False
closed_date = None
closer = None
components = ['IDLE']
creation = <Date 2011-06-22.17:59:58.252>
creator = 'Jacob.VB'
dependencies = []
files = ['25226', '35592']
hgrepos = []
issue_num = 12387
keywords = ['patch', 'easy']
message_count = 14.0
messages = ['138828', '138842', '138843', '158303', '158309', '158312', '158354', '158368', '212611', '212612', '218776', '220331', '220332', '220338']
nosy_count = 10.0
nosy_names = ['rhettinger', 'terry.reedy', 'kbk', 'ned.deily', 'roger.serwy', 'westley.martinez', 'python-dev', 'Jacob.VB', 'Saimadhav.Heblikar', 'dpg']
pr_nums = ['32245']
priority = 'normal'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue12387'
versions = ['Python 3.6', 'Python 3.7']
    @jvanburen
    Copy link
    Mannequin Author

    jvanburen mannequin commented Jun 22, 2011

    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.

    @jvanburen jvanburen mannequin added topic-IDLE type-bug An unexpected behavior, bug, or error labels Jun 22, 2011
    @jvanburen jvanburen mannequin changed the title IDLE save hotkey problem IDLE save keyboard shortcut problem Jun 22, 2011
    @terryjreedy
    Copy link
    Member

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

    @jvanburen
    Copy link
    Mannequin Author

    jvanburen mannequin commented Jun 23, 2011

    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.

    @serwy
    Copy link
    Mannequin

    serwy mannequin commented Apr 15, 2012

    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?

    @serwy serwy mannequin added the easy label Apr 15, 2012
    @rhettinger
    Copy link
    Contributor

    I would like to see them all changed.

    @terryjreedy
    Copy link
    Member

    I agree; lets be consistently lenient.

    @serwy
    Copy link
    Mannequin

    serwy mannequin commented Apr 15, 2012

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

    @terryjreedy
    Copy link
    Member

    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.

    @westleymartinez
    Copy link
    Mannequin

    westleymartinez mannequin commented Mar 3, 2014

    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

    @ned-deily
    Copy link
    Member

    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.

    @terryjreedy
    Copy link
    Member

    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.

    @python-dev
    Copy link
    Mannequin

    python-dev mannequin commented Jun 12, 2014

    New changeset 55fed3eae14b by Terry Jan Reedy in branch '2.7':
    Issue bpo-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 bpo-12387: Add missing upper(lower)case versions of default Windows key
    http://hg.python.org/cpython/rev/25fd9aeeff91

    @terryjreedy
    Copy link
    Member

    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.

    @SaimadhavHeblikar
    Copy link
    Mannequin

    SaimadhavHeblikar mannequin commented Jun 12, 2014

    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.

    @terryjreedy terryjreedy added the 3.7 (EOL) end of life label Jun 30, 2017
    @terryjreedy terryjreedy self-assigned this Jun 30, 2017
    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    @bedevere-bot bedevere-bot mentioned this issue Sep 18, 2022
    Open
    @terryjreedy terryjreedy removed the 3.7 (EOL) end of life label Feb 26, 2024
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Assignees

    @terryjreedy terryjreedy

    Labels
    easy topic-IDLE type-bug An unexpected behavior, bug, or error
    Projects
    IDLE Issues
    Status: In Progress
    Milestone
    No milestone
    Development

    No branches or pull requests
    3 participants
    @rhettinger @ned-deily @terryjreedy