Re: New key binding syntax

[Alexandre Garreau]

Le jeudi 4 novembre 2021, 09:53:23 CET Yuri Khan a écrit :
> 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.

But what happens after 7 consecutive down on a typical keyboard then? why 
this limitation since each key succeeds the previous one?

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

Wouldn’t it be useful if emacs implementation of user input was separated 
in a C library? it’s C right? and emacs is not the only software to 
support key sequences as commands, readline does just the same… and it 
could benefit from a such feature as well.  Moreover, emacs’ code must be, 
I guess, very stable and old (in the good sense), and must benefit from 
portability to many platforms and environments (legacy terminal (why not 
more modern extensions to it such as Kitty) + several graphical ones at 
least) and the maintainance that comes with  it, and potential future 
features (such as mouse gestures and dragging, etc.).  It could be the 
kind of library that rarely changes and is often copied in-tree and 
statically linked, just as readline is by default.  Btw emacs could be 
configured to read some config and bing some keys from the same config file as 
readline’s.

Furthermore, add to that (key chords) the support of combos (key sequences 
pressed at more or less short intervals to be considered as a complete 
sequence before to be considered over), and you would get a pretty high 
level library working for pretty much anything compatible with C, on many 
platform, with great stability, and supporting/promoting emacs’ way of 
(possibly complicated) stating/binding user input with simple readeable 
strings such as “C-x C-l l”.  A such complex library could be very useful 
to video games as well as for any application wanting a more complex 
management of user input: I guess specific GTK code doesn’t allow for 
keysequences and emacs reimplement on top of that right?

Currently I find that most used framework for that (SDL, or game engines 
such as irlicht, uses a both less powerful and more complicated way of 
binding user input than what is found in emacs or readline).

> It would not be available in some terminal
> emulators, that’s all.

well: the current (dirty and hacky) implementation, since it uses emacs’ 
primitives, works also on terminals.  But you better not press chords too 
fast or too slowly u.u that could be optionally used

A further problem is that it uses a different syntax (and a different 
function for binding keys), rather than changing/redefining/extending/
advicing the default one.