Re: New key binding syntax

[Yuri Khan]

On Thu, 4 Nov 2021 at 09:34, Richard Stallman <rms@gnu.org> wrote:

> That sounds nice, but using non-modifier keys as modifiers has an
> inherent problem: those keys are supposed to do rollover.
> If you press a, and while holding it down, press b, that is supposed
> to mean a followed by b.
>
> To make that count as "b modified by a", we would need to change how
> the keyboard handles the a key.

These days, the keyboard does not handle this kind of rollover. All it
does is report the up/down state of all 8 standard modifier keys (left
and right GUI, Alt, Ctrl, Shift) and up to 6 normal keys that are
down. (There are ways for a keyboard to be able to report more than 6;
such boards are advertised as NKRO (N-Key Rollover) and it’s a gamer
feature.)

The rollover behavior works entirely on the application side, where
the OS and the GUI toolkit send events like “the key at position AB02
was pressed while the left Alt is down; by the way, the character for
this key in the current layout is x”. If the application reacts to key
press and autorepeat events and takes the character and modifiers from
them immediately, the “AC01 down (char a), AB05 down (char b), AC01 up
(char a), AB05 up (char b)” sequence results in an “a then b” text
input. But some applications (notably games) just track the whole bit
array of keys.

Modern terminal emulators such as Kitty also make this kind of events
available, although, for backward compatibility reasons, the
application has to detect that this protocol extension is supported
and opt-in to using it.

To recap: If Emacs decided to support chord input, it would not
require any hardware modifications or OS tweaks, it would be a feature
entirely in Emacs. It would not be available in some terminal
emulators, that’s all.