By default numbers are interpreted as counts for bindings. Making this
behavior configurable allows for emacs-like bindings, where number keys
are passed through.
Before the changes in this commit, we've had to have a subclassed parser for
every mode, even if there was no special key handling going on in that mode.
With a couple of changes, we can avoid many of those subclasses and only have
subclasses for bigger changes (like hint or register modes).
- The awkward handling of self._modename in _read_config() is now removed.
_read_config() doesn't take an argument, always uses the mode in self._mode
and gets called from __init__.
- BaseKeyParser takes the mode as an argument to __init__.
- The class attributes (do_log/passthrough/supports_count) now also get passed
via the constructor.
Turns out str.isdigit() also handles ² as a digit, but int('²') causes a
ValueError.
Here we use `string.digits` instead, which is '0123456789'.
Fixes#3743
1899e313fd as a fix for #3631 broke :unbind, as
the config system treats None and '' equally.
Instead, allow None/'' again, but just handle it as "no binding".
This mostly reverts 4ef5db1bc4 for #1966, but
fixes#3684 by allowing numbers to be bound again. If the user wants to bind
numbers instead of using them for a count, why not let them.
When pressing a key which doesn't exist as Qt.Key, we don't get Qt.Key_unknown
like we'd expect, but we get 0x0 instead...
Let's add that as a new "nil" key (to not conflict with None/unknown/zero/...)
and handle it appropriately.
This can be reproduced by doing:
setxkbmap -layout us,gr -option grp:alt_shift_toggle
and pressing Alt-Shift/Shift-Alt.
Turns out when we press yY, we get three events:
Qt.Key_Y, Qt.NoModifier
Qt.Key_Shift, Qt.ShiftModifier
Qt.Key_Y, Qt.ShiftModifier
If we don't ignore the second one, our keychain will be interrupted by the Shift
keypress.
This initially seemed like a nice feature, but it means 0 can't be bound
as a separate key anymore, and 0<Esc> gives weird error messages...
Reverts #1953.
Fixes#2032.