gh-55646: Do not crash IDLE on an invalid key binding

[serhiy-storchaka]

A typo in a custom key binding entered via Advanced Key Binding (which is not validated), such as <Alt-Key-up> instead of <Alt-Key-Up>, crashed IDLE at startup:

  File ".../idlelib/multicall.py", line ..., in bind
    self.__binders[triplet[1]].bind(triplet, func)
  ...
_tkinter.TclError: bad event type or keysym "up"

MultiCall.event_add stores the parsed sequence without validating the keysym, so the TclError is raised later, when a virtual event is bound and MultiCall performs the actual Tk bind. With no window yet, IDLE just exits.

Catch TclError at both binder call sites (MultiCall.bind and MultiCall.event_add) and ignore the invalid binding with a warning naming it. The bind path also drops the bad sequence from the virtual event, which avoids a secondary ValueError if it is later rebound or unbound.

🤖 Generated with Claude Code

• Issue: IDLE crash on startup with typo in config-keys.cfg #55646

[terryjreedy]

The issue is an example of making the good the enemy of the adequate. Unexpected crashes/exits are bad and this is definately better than no fix.

The merge conflict was due to this being the 2nd patch to add tests at the end of test_multicall. The local interface had a button to accept both additions.

I also looked at Serwy's patch: https://bugs.python.org/file24351/issue11437.patch.
His concern about repeated processing is mostly moot for most users. We merged all the IDLE feature extensions into the main code about a decade ago, leaving only a test extension.

Main question: Why catch errors in multicall rather than configparser? Does every sequence get run through multicall? Does this catch more errors?

[serhiy-storchaka]

Note that "Accept both" eats a blank line between fragments. You have to add it after pressing "Accept both" while you are in the online editor. I fixed this.

Yes, every configured key binding goes through MultiCall. MultiCall is the single choke point where a binding string is actually handed to Tk.

Serwy's patch also works. But it pulls a Tk root plus a modal dialog into config code that also runs headless (tests, the subprocess). Naming the bad key and suggesting a reconfigure is a nice touch, which I've added to the warning.

[serhiy-storchaka]

@terryjreedy, does my answer above address your question? Every configured key binding does go through MultiCall, so it is the single place where an invalid sequence can be caught, and it also catches sequences that the config code cannot check without a Tk root.

The same kind of problem exists for other config values. An invalid color in a user theme crashes the Settings dialog (#85604). A config file that cannot be parsed at all (a syntax or encoding error) was handled in #152764. Fonts are already tolerant: a bad size falls back to the default with a warning, and Tk substitutes an unknown family.

[miss-islington-app]

Thanks @serhiy-storchaka for the PR, and @terryjreedy for merging it 🌮🎉.. I'm working now to backport this PR to: 3.13, 3.14, 3.15.
🐍🍒⛏🤖

[bedevere-app]

GH-158149 is a backport of this pull request to the 3.15 branch.

[miss-islington-app]

Sorry, @serhiy-storchaka and @terryjreedy, I could not cleanly backport this to 3.13 due to a conflict.
Please backport using cherry_picker on command line.

cherry_picker b9546455ab0f65af65b0b69e86e7a2f65d287c16 3.13

[bedevere-app]

GH-158150 is a backport of this pull request to the 3.14 branch.

[terryjreedy]

Serhiy: Conflict stopped 3.13 backport.

[bedevere-app]

GH-158265 is a backport of this pull request to the 3.13 branch.