[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: New key binding syntax
From: |
Alexandre Garreau |
Subject: |
Re: New key binding syntax |
Date: |
Fri, 05 Nov 2021 07:08:22 +0100 |
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.
Re: New key binding syntax, Dmitry Gutov, 2021/11/02
Re: New key binding syntax, Alexandre Garreau, 2021/11/02
- Re: New key binding syntax, Richard Stallman, 2021/11/03
- Re: New key binding syntax, Yuri Khan, 2021/11/04
- Re: New key binding syntax,
Alexandre Garreau <=
- Re: New key binding syntax, Yuri Khan, 2021/11/05
- Re: New key binding syntax, Alexandre Garreau, 2021/11/05
- Re: New key binding syntax, Yuri Khan, 2021/11/05
- Re: New key binding syntax, Alexandre Garreau, 2021/11/05
- Re: New key binding syntax, Yuri Khan, 2021/11/05
Re: New key binding syntax, Richard Stallman, 2021/11/05
Re: New key binding syntax, Alexandre Garreau, 2021/11/05
Re: New key binding syntax, Richard Stallman, 2021/11/07
Re: New key binding syntax, Emanuel Berg, 2021/11/07
RE: [External] : New key binding syntax, Drew Adams, 2021/11/08