Physical keyboard events

Physical keyboard events

[Cecilio Pardo]

Hello,

I'm planning to implement physical key press/release events for emacs.
I would add a new element to 'enum event_kind', that in turn would
send a new input event. This input event will be bound in
'special-event-map' so that it will not modify the normal flow of
keyboard input. Platform dependent code would send these events
on key press and release.

Then a lisp fuction can be bound to this on the special-event-map, to
implement the detection of:

- double/triple tap on Shift, Control, Alt, etc
- Long presses on Shift, Control, Alt, etc.

This actions could be bound to commands, or could add a modififer
(Super, Hyper) to next commands.

And make Tetris independent of the keyboard repeat rate :)

Has something like this been discussed before, so I can check?

Re: Physical keyboard events

[Eli Zaretskii]

> Date: Tue, 29 Oct 2024 00:15:22 +0100
> From: Cecilio Pardo <cpardo@imayhem.com>
> 
> Hello,
> 
> I'm planning to implement physical key press/release events for emacs.
> I would add a new element to 'enum event_kind', that in turn would
> send a new input event. This input event will be bound in
> 'special-event-map' so that it will not modify the normal flow of
> keyboard input. Platform dependent code would send these events
> on key press and release.

I hope these new events will not be sent at all times, only when some
optional variable is set (similar to track-mouse, perhaps).  I
wouldn't want Emacs to start processing press/release events on Shift
or Ctrl unless a Lisp program needs that, and I don't think we want to
change our processing of keyboard such that instead of a single
keypress with modifiers we need to process multiple key-press and
key-release events when the user simply types on the keyboard.

Physical keys also raise the issue of supporting input methods,
keyboard layout switches, etc.

> Then a lisp fuction can be bound to this on the special-event-map, to
> implement the detection of:
> 
> - double/triple tap on Shift, Control, Alt, etc
> - Long presses on Shift, Control, Alt, etc.
> 
> This actions could be bound to commands, or could add a modififer
> (Super, Hyper) to next commands.
> 
> And make Tetris independent of the keyboard repeat rate :)
> 
> Has something like this been discussed before, so I can check?

No, I don't think so, although we get feature requests for something
like that from time to time.

However, on what systems and which Emacs configurations will it be
possible to provide such a feature?

Thanks.

Re: Physical keyboard events

[Cecilio Pardo]

On 29/10/2024 14:40, Eli Zaretskii wrote:

>> I'm planning to implement physical key press/release events for emacs.
>> I would add a new element to 'enum event_kind', that in turn would
>> send a new input event. This input event will be bound in
>> 'special-event-map' so that it will not modify the normal flow of
>> keyboard input. Platform dependent code would send these events
>> on key press and release.
> 
> I hope these new events will not be sent at all times, only when some
> optional variable is set (similar to track-mouse, perhaps).  I
> wouldn't want Emacs to start processing press/release events on Shift
> or Ctrl unless a Lisp program needs that, and I don't think we want to
> change our processing of keyboard such that instead of a single
> keypress with modifiers we need to process multiple key-press and
> key-release events when the user simply types on the keyboard.

Thats why the events will be bound in special-event-map. Nobody will see 
them, except for the code that handles them.  We can of course 
completely disable them with a variable.

> Physical keys also raise the issue of supporting input methods,
> keyboard layout switches, etc.

I will define a list of keys: LeftShit, RightShift, LeftControl, etc. 
The platform dependent code will decide which one was pressed. As events 
will be invisible, I don't think we will interfere with input methods.

> However, on what systems and which Emacs configurations will it be
> possible to provide such a feature?

I think all GUI systems can use this.

Re: Physical keyboard events

[Peter Feigl]

> I will define a list of keys: LeftShit, RightShift, LeftControl, etc. 
> The platform dependent code will decide which one was pressed. As events 
> will be invisible, I don't think we will interfere with input methods.

I caution you to think about this very well, there are *very* many
non-standard keyboards or remapped keyboards out there, where users
expect everything to work.

In general, it is best to leave the mapping of physical keys to intended
keypresses to whatever the operating system provides. In the specific
case of Xorg, please only look at the keysyms, do not try to do anything
magical with the scancodes, this will only result in a broken
implementation.

I understand the wish to have this, but it is a way more complex topic
than it looks like from a first glance.

I have had to deal with way too many bad implementations of this than
wanting to deal with it in Emacs as well :-/

Sorry for the criticism, in case you have already thought about all of
this and solved it, I'd really be interested in hearing more about it!

Greetings,
Peter

Re: Physical keyboard events

[Cecilio Pardo]

On 29/10/2024 16:38, Peter Feigl wrote:

>> I will define a list of keys: LeftShit, RightShift, LeftControl, etc.
>> The platform dependent code will decide which one was pressed. As events
>> will be invisible, I don't think we will interfere with input methods.
> 
> I caution you to think about this very well, there are *very* many
> non-standard keyboards or remapped keyboards out there, where users
> expect everything to work.
> 
> In general, it is best to leave the mapping of physical keys to intended
> keypresses to whatever the operating system provides. In the specific
> case of Xorg, please only look at the keysyms, do not try to do anything
> magical with the scancodes, this will only result in a broken
> implementation.
> 
> I understand the wish to have this, but it is a way more complex topic
> than it looks like from a first glance.
> 
> I have had to deal with way too many bad implementations of this than
> wanting to deal with it in Emacs as well :-/
> 
> Sorry for the criticism, in case you have already thought about all of
> this and solved it, I'd really be interested in hearing more about it!

Thanks for the insight. I will keep it simple and be conservative. And 
ready to throw it all away if the result asks for it. :)

Re: Physical keyboard events

[James Thomas]

Peter Feigl wrote:

>> I will define a list of keys: LeftShit, RightShift, LeftControl, etc.
>> The platform dependent code will decide which one was pressed. As events
>> will be invisible, I don't think we will interfere with input methods.
>
> I caution you to think about this very well, there are *very* many
> non-standard keyboards or remapped keyboards out there, where users
> expect everything to work.
>
> In general, it is best to leave the mapping of physical keys to intended
> keypresses to whatever the operating system provides. In the specific
> case of Xorg, please only look at the keysyms, do not try to do anything
> magical with the scancodes, this will only result in a broken
> implementation.
>
> I understand the wish to have this, but it is a way more complex topic
> than it looks like from a first glance.
>
> I have had to deal with way too many bad implementations of this than
> wanting to deal with it in Emacs as well :-/
>
> Sorry for the criticism, in case you have already thought about all of
> this and solved it, I'd really be interested in hearing more about it!

I feel the same way. On that note, isn't it possible to achieve the same
thing in Xorg simply by sending fake key or fake locked modifier events?

IIRC, just using xkbcomp.

--

Re: Physical keyboard events

[Eli Zaretskii]

> Date: Tue, 29 Oct 2024 16:07:16 +0100
> Cc: emacs-devel@gnu.org
> From: Cecilio Pardo <cpardo@imayhem.com>
> 
> On 29/10/2024 14:40, Eli Zaretskii wrote:
> 
> >> I'm planning to implement physical key press/release events for emacs.
> >> I would add a new element to 'enum event_kind', that in turn would
> >> send a new input event. This input event will be bound in
> >> 'special-event-map' so that it will not modify the normal flow of
> >> keyboard input. Platform dependent code would send these events
> >> on key press and release.
> > 
> > I hope these new events will not be sent at all times, only when some
> > optional variable is set (similar to track-mouse, perhaps).  I
> > wouldn't want Emacs to start processing press/release events on Shift
> > or Ctrl unless a Lisp program needs that, and I don't think we want to
> > change our processing of keyboard such that instead of a single
> > keypress with modifiers we need to process multiple key-press and
> > key-release events when the user simply types on the keyboard.
> 
> Thats why the events will be bound in special-event-map. Nobody will see 
> them, except for the code that handles them.  We can of course 
> completely disable them with a variable.

Even if no one sees them, bombarding the Emacs event queue with
useless events will have its effect: Emacs will become more sluggish,
some while-no-input loops will unexpectedly exit just because the user
happened to touch the Shift key for some reason, etc.

> > Physical keys also raise the issue of supporting input methods,
> > keyboard layout switches, etc.
> 
> I will define a list of keys: LeftShit, RightShift, LeftControl, etc. 
> The platform dependent code will decide which one was pressed. As events 
> will be invisible, I don't think we will interfere with input methods.

I meant the non-modifier keys.  When some OS feature redefines a key,
low-level events will not know that, and will still consider the key
labeled 'a' as 'a', even though I might have switched the keyboard to
another language, where the key labeled 'a' actually produces a
completely different character, say, 'ש'.

> > However, on what systems and which Emacs configurations will it be
> > possible to provide such a feature?
> 
> I think all GUI systems can use this.

So X (with or without any toolkit we support), PGTK, MS-Windows, and
macOS -- all those let applications access low-level key events?

Re: Physical keyboard events

[Yuri Khan]

On Tue, 29 Oct 2024 at 23:46, Eli Zaretskii <eliz@gnu.org> wrote:

> I meant the non-modifier keys.  When some OS feature redefines a key,
> low-level events will not know that, and will still consider the key
> labeled 'a' as 'a', even though I might have switched the keyboard to
> another language, where the key labeled 'a' actually produces a
> completely different character, say, 'ש'.

From where I stand, that would be a feature, in some carefully chosen
cases. When I’m switched to a layout where the ‘a’ key produces an ‘ф’
character, or an ‘α’, or a ち, I’d still want Ctrl+this key to behave
as C-a.

Re: Physical keyboard events

[Eli Zaretskii]

> From: Yuri Khan <yuri.v.khan@gmail.com>
> Date: Tue, 29 Oct 2024 23:55:49 +0700
> Cc: Cecilio Pardo <cpardo@imayhem.com>, emacs-devel@gnu.org
> 
> On Tue, 29 Oct 2024 at 23:46, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > I meant the non-modifier keys.  When some OS feature redefines a key,
> > low-level events will not know that, and will still consider the key
> > labeled 'a' as 'a', even though I might have switched the keyboard to
> > another language, where the key labeled 'a' actually produces a
> > completely different character, say, 'ש'.
> 
> >From where I stand, that would be a feature, in some carefully chosen
> cases. When I’m switched to a layout where the ‘a’ key produces an ‘ф’
> character, or an ‘α’, or a ち, I’d still want Ctrl+this key to behave
> as C-a.

Yes, but you want that _only_ for keys with modifiers.  Which is not
what will happen.  Some feature...

Re: Physical keyboard events

[Max Nikulin]

On 30/10/2024 00:46, Eli Zaretskii wrote:
>> From: Yuri Khan Date: Tue, 29 Oct 2024 23:55:49 +0700
>> When I’m switched to a layout where the ‘a’ key produces an ‘ф’
>> character, or an ‘α’, or a ち, I’d still want Ctrl+this key to behave
>> as C-a.
> 
> Yes, but you want that _only_ for keys with modifiers.  Which is not
> what will happen.  Some feature...

Not *for key with modifiers*, but during lookup in keymaps. There are 
enough keybindings that include keys without modifiers. It is a 
recurring confusion that appears in every discussion of related bugs and 
in mailing list threads, e.g.
<https://debbugs.gnu.org/43830>
"keyboard layout handling incompatible with rest of the OS"
Perhaps it is impossible to achieve in terminal frames.

Modifier-only gestures sounds like a different feature though.

Cecilio, in the case of severe resistance you may consider another 
approach: sniff keyboard events at lower level (xinput2? IBus plugin?) 
by a dedicated daemon and emit D-Bus events that may be interpreted by 
Emacs (and other applications). The bonus is support of Emacs frames 
inside terminal applications. Isolation of applications in Wayland may 
be a trouble, but perhaps some compositors support configurable gestures 
out of the box.

Re: Physical keyboard events

[Yuri Khan]

On Wed, 30 Oct 2024 at 10:22, Max Nikulin <manikulin@gmail.com> wrote:

> Not *for key with modifiers*, but during lookup in keymaps. There are
> enough keybindings that include keys without modifiers.

I’m going to posit the hypothesis that the *only* command for which it
makes sense to use the keysym of the current layout is
‘self-insert-command’.

Everything else wants the keysym of “the” Latin-based layout if there
is one and only one; the keycode if there is none; and some heuristic
tiebreaker for the case where the user has more than one Latin-based
layout configured.

Re: Physical keyboard events

[Peter Feigl]

> Everything else wants the keysym of “the” Latin-based layout if there
> is one and only one; the keycode if there is none; and some heuristic
> tiebreaker for the case where the user has more than one Latin-based
> layout configured.

I have a keyboard that has dvorak-like layout and emits these keycodes
*physically*. There are many other variations of this around. The
keycode tells you *nothing* about the physical location of a key, so if
you were to use it for – as an example – using WASD for moving a
character around the screen, that would be entirely useless for these
keyboards, because WASD are *not* in the positions you assume them to
be.

Of course you could argue that that's just a few percent of the users,
so we shouldn't care about them, they'll cope in some other way.

I've seen way too many applications (e.g. many games) try to guess the
active keyboard layout, and invariably fail on anything non-standard.

There's a reason why Xorg allows to remap everything, it would be a
shame to not support all this flexibility.

Greetings,
Peter

Re: Physical keyboard events

[Eli Zaretskii]

> From: Yuri Khan <yuri.v.khan@gmail.com>
> Date: Wed, 30 Oct 2024 13:28:20 +0700
> Cc: emacs-devel@gnu.org
> 
> On Wed, 30 Oct 2024 at 10:22, Max Nikulin <manikulin@gmail.com> wrote:
> 
> > Not *for key with modifiers*, but during lookup in keymaps. There are
> > enough keybindings that include keys without modifiers.
> 
> I’m going to posit the hypothesis that the *only* command for which it
> makes sense to use the keysym of the current layout is
> ‘self-insert-command’.
> 
> Everything else wants the keysym of “the” Latin-based layout if there
> is one and only one; the keycode if there is none; and some heuristic
> tiebreaker for the case where the user has more than one Latin-based
> layout configured.

How do you suggest to arrange for a low-level keyboard interface to
know which kind of Emacs command attempted to read the keyboard?

Moreover, what about type-ahead?  When Emacs is busy, the user can
type quite a lot of commands, and the keyboard processing cannot know
at that point which Emacs commands will actually read those queued
keys.

IOW, I don't understand how to use your hypothesis, even if it is
true, in practice.

Re: Physical keyboard events

[Yuri Khan]

On Wed, 30 Oct 2024 at 22:27, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Yuri Khan <yuri.v.khan@gmail.com>
> > Date: Wed, 30 Oct 2024 13:28:20 +0700
> > Cc: emacs-devel@gnu.org

> > I’m going to posit the hypothesis that the *only* command for which it
> > makes sense to use the keysym of the current layout is
> > ‘self-insert-command’.
> >
> > Everything else wants the keysym of “the” Latin-based layout if there
> > is one and only one; the keycode if there is none; and some heuristic
> > tiebreaker for the case where the user has more than one Latin-based
> > layout configured.
>
> How do you suggest to arrange for a low-level keyboard interface to
> know which kind of Emacs command attempted to read the keyboard?

Since it’s not clairvoyant, it would need to save enough information
for the keymap lookup code downstream. Specifically (XKB/X11 case):
state of modifiers, keycode, keysym according to the currently active
group, and keysym according to the appropriate Latin-based group.

Then, at the time of keymap lookup:

* Look up the active modifiers + active group keysym.
  * If this yields ‘self-insert-command’ or another command
specifically whitelisted, return that.
* Look up the active modifiers + keysym from the Latin-based group. Return that.

Test case: If a mode keymap binds both ‘/’ and ‘.’, and a key produces
‘/’ in the Latin layout and ‘.’ in Cyrillic layout, then the ‘/’
command shall be executed regardless of whether Latin or Cyrillic
layout is active.

Re: Physical keyboard events

[Eli Zaretskii]

> From: Yuri Khan <yuri.v.khan@gmail.com>
> Date: Thu, 31 Oct 2024 00:13:31 +0700
> Cc: manikulin@gmail.com, emacs-devel@gnu.org
> 
> On Wed, 30 Oct 2024 at 22:27, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > > From: Yuri Khan <yuri.v.khan@gmail.com>
> > > Date: Wed, 30 Oct 2024 13:28:20 +0700
> > > Cc: emacs-devel@gnu.org
> 
> > > I’m going to posit the hypothesis that the *only* command for which it
> > > makes sense to use the keysym of the current layout is
> > > ‘self-insert-command’.
> > >
> > > Everything else wants the keysym of “the” Latin-based layout if there
> > > is one and only one; the keycode if there is none; and some heuristic
> > > tiebreaker for the case where the user has more than one Latin-based
> > > layout configured.
> >
> > How do you suggest to arrange for a low-level keyboard interface to
> > know which kind of Emacs command attempted to read the keyboard?
> 
> Since it’s not clairvoyant, it would need to save enough information
> for the keymap lookup code downstream. Specifically (XKB/X11 case):
> state of modifiers, keycode, keysym according to the currently active
> group, and keysym according to the appropriate Latin-based group.
> 
> Then, at the time of keymap lookup:
> 
> * Look up the active modifiers + active group keysym.
>   * If this yields ‘self-insert-command’ or another command
> specifically whitelisted, return that.
> * Look up the active modifiers + keysym from the Latin-based group. Return that.

How do you know which keymap to look up and for which character,
before you decide which character to produce?

> Test case: If a mode keymap binds both ‘/’ and ‘.’, and a key produces
> ‘/’ in the Latin layout and ‘.’ in Cyrillic layout, then the ‘/’
> command shall be executed regardless of whether Latin or Cyrillic
> layout is active.

What if '/' is bound to self-insert-command, but '.' to something
else: what do you return then?

Re: Physical keyboard events

[Dov Grobgeld]

Switching to a different keyboard language causes all navigation
keyboard shortcuts to fail by default. This is why I found myself
adding the following to my .emacs file. I agree it would be nice if
there was some automatic way of creating this mapping, but using
keycodes, does not seem to be a correct way to do it.

;; some motion bindings in Hebrew mode that reflect key
;; positions for Dvorak.
(global-set-key [(control ?ש)] 'move-beginning-of-line)
(global-set-key [(control ?ג)] 'move-end-of-line)
(global-set-key [(control ?ר)] 'previous-line)
(global-set-key [(control ?ך)] 'next-line)
(global-set-key [(control ?ה)] 'kill-line)
(global-set-key [(control ?ף)] 'isearch-forward)
(global-set-key [(control ?ם)] 'isearch-backward)
(global-set-key [(control ?ץ)] 'scroll-up-command)
(global-set-key [(meta ?ץ)] 'scroll-down-command)
(global-set-key [(meta ?ט)] 'forward-word)
(global-set-key [(control ?ט)] 'forward-char)
(global-set-key [(meta ?מ)] 'backward-word)
(global-set-key [(control ?מ)] 'backward-char)
(define-key isearch-mode-map [(control ?ף)] 'isearch-repeat-forward)
(define-key isearch-mode-map [(control ?ם)] 'isearch-repeat-backward)
(global-set-key [(control ?נ) (control ?ף)] 'save-buffer)

On Wed, Oct 30, 2024 at 7:38 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Yuri Khan <yuri.v.khan@gmail.com>
> > Date: Thu, 31 Oct 2024 00:13:31 +0700
> > Cc: manikulin@gmail.com, emacs-devel@gnu.org
> >
> > On Wed, 30 Oct 2024 at 22:27, Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > > > From: Yuri Khan <yuri.v.khan@gmail.com>
> > > > Date: Wed, 30 Oct 2024 13:28:20 +0700
> > > > Cc: emacs-devel@gnu.org
> >
> > > > I’m going to posit the hypothesis that the *only* command for which it
> > > > makes sense to use the keysym of the current layout is
> > > > ‘self-insert-command’.
> > > >
> > > > Everything else wants the keysym of “the” Latin-based layout if there
> > > > is one and only one; the keycode if there is none; and some heuristic
> > > > tiebreaker for the case where the user has more than one Latin-based
> > > > layout configured.
> > >
> > > How do you suggest to arrange for a low-level keyboard interface to
> > > know which kind of Emacs command attempted to read the keyboard?
> >
> > Since it’s not clairvoyant, it would need to save enough information
> > for the keymap lookup code downstream. Specifically (XKB/X11 case):
> > state of modifiers, keycode, keysym according to the currently active
> > group, and keysym according to the appropriate Latin-based group.
> >
> > Then, at the time of keymap lookup:
> >
> > * Look up the active modifiers + active group keysym.
> >   * If this yields ‘self-insert-command’ or another command
> > specifically whitelisted, return that.
> > * Look up the active modifiers + keysym from the Latin-based group. Return that.
>
> How do you know which keymap to look up and for which character,
> before you decide which character to produce?
>
> > Test case: If a mode keymap binds both ‘/’ and ‘.’, and a key produces
> > ‘/’ in the Latin layout and ‘.’ in Cyrillic layout, then the ‘/’
> > command shall be executed regardless of whether Latin or Cyrillic
> > layout is active.
>
> What if '/' is bound to self-insert-command, but '.' to something
> else: what do you return then?
>

Re: Physical keyboard events

[Juri Linkov]

> Switching to a different keyboard language causes all navigation
> keyboard shortcuts to fail by default. This is why I found myself
> adding the following to my .emacs file. I agree it would be nice if
> there was some automatic way of creating this mapping, but using
> keycodes, does not seem to be a correct way to do it.
>
> ;; some motion bindings in Hebrew mode that reflect key
> ;; positions for Dvorak.
> (global-set-key [(control ?ש)] 'move-beginning-of-line)
> (global-set-key [(control ?ג)] 'move-end-of-line)
> (global-set-key [(control ?ר)] 'previous-line)
> (global-set-key [(control ?ך)] 'next-line)
> (global-set-key [(control ?ה)] 'kill-line)
> (global-set-key [(control ?ף)] 'isearch-forward)
> (global-set-key [(control ?ם)] 'isearch-backward)
> (global-set-key [(control ?ץ)] 'scroll-up-command)
> (global-set-key [(meta ?ץ)] 'scroll-down-command)
> (global-set-key [(meta ?ט)] 'forward-word)
> (global-set-key [(control ?ט)] 'forward-char)
> (global-set-key [(meta ?מ)] 'backward-word)
> (global-set-key [(control ?מ)] 'backward-char)
> (define-key isearch-mode-map [(control ?ף)] 'isearch-repeat-forward)
> (define-key isearch-mode-map [(control ?ם)] 'isearch-repeat-backward)
> (global-set-key [(control ?נ) (control ?ף)] 'save-buffer)

There is the automatic way of creating such mapping
by using the package

  https://github.com/a13/reverse-im.el

Then you can customize it to any input method, e.g.:

  (reverse-im-input-methods '("hebrew"))

Re: Physical keyboard events

[Eli Zaretskii]

> From: Dov Grobgeld <dov.grobgeld@gmail.com>
> Date: Wed, 30 Oct 2024 21:26:21 +0200
> Cc: Yuri Khan <yuri.v.khan@gmail.com>, manikulin@gmail.com, emacs-devel@gnu.org
> 
> Switching to a different keyboard language causes all navigation
> keyboard shortcuts to fail by default.

That's window-system specific, I think.  It doesn't happen on
MS-Windows, for example.

Re: Physical keyboard events

[Yuri Khan]

On Thu, 31 Oct 2024 at 00:37, Eli Zaretskii <eliz@gnu.org> wrote:

> > * Look up the active modifiers + active group keysym.
> >   * If this yields ‘self-insert-command’ or another command
> > specifically whitelisted, return that.
> > * Look up the active modifiers + keysym from the Latin-based group. Return that.
>
> How do you know which keymap to look up and for which character,
> before you decide which character to produce?

What seems to be the difficulty with the description above? The first
lookup happens the same way as it currently does. For the second
lookup, pretend the user remembered to switch to their preferred
Latin-based layout before hitting the keys.

> > Test case: If a mode keymap binds both ‘/’ and ‘.’, and a key produces
> > ‘/’ in the Latin layout and ‘.’ in Cyrillic layout, then the ‘/’
> > command shall be executed regardless of whether Latin or Cyrillic
> > layout is active.
>
> What if '/' is bound to self-insert-command, but '.' to something
> else: what do you return then?

What kind of mode would allow self-insertion for some characters but
use others for commands? Like maybe Calc, where ‘.’ is the decimal
point but ‘/’ is the division command?

In this case I think using ‘.’ for entering the decimal point wins,
and the division command has to be invoked by either the kp-divide key
or the {/ \} key. That is, calc-divide has to be whitelisted as
invocable with the national layout.

Re: Physical keyboard events

[Eli Zaretskii]

> From: Max Nikulin <manikulin@gmail.com>
> Date: Wed, 30 Oct 2024 09:56:30 +0700
> 
> On 30/10/2024 00:46, Eli Zaretskii wrote:
> >> From: Yuri Khan Date: Tue, 29 Oct 2024 23:55:49 +0700
> >> When I’m switched to a layout where the ‘a’ key produces an ‘ф’
> >> character, or an ‘α’, or a ち, I’d still want Ctrl+this key to behave
> >> as C-a.
> > 
> > Yes, but you want that _only_ for keys with modifiers.  Which is not
> > what will happen.  Some feature...
> 
> Not *for key with modifiers*, but during lookup in keymaps.

What Emacs key is NOT looked up in a keymap?  They all are.

So I don't understand what you are saying here.

> There are 
> enough keybindings that include keys without modifiers. It is a 
> recurring confusion that appears in every discussion of related bugs and 
> in mailing list threads, e.g.
> <https://debbugs.gnu.org/43830>
> "keyboard layout handling incompatible with rest of the OS"

That's exactly why I said "with modifiers": that bug report is about
C-s and the likes.  By contrast, when the keyboard language is
switched, you do NOT want the s/ы key to generate s instead of ы.

Re: Physical keyboard events

[Max Nikulin]

On 30/10/2024 22:21, Eli Zaretskii wrote:
>> From: Max Nikulin Date: Wed, 30 Oct 2024 09:56:30 +0700
>> On 30/10/2024 00:46, Eli Zaretskii wrote:
>>>> From: Yuri Khan Date: Tue, 29 Oct 2024 23:55:49 +0700
>>>> When I’m switched to a layout where the ‘a’ key produces an ‘ф’
>>>> character, or an ‘α’, or a ち, I’d still want Ctrl+this key to behave
>>>> as C-a.
>>>
>>> Yes, but you want that _only_ for keys with modifiers.  Which is not
>>> what will happen.  Some feature...
>>
>> Not *for key with modifiers*, but during lookup in keymaps.
[...]
>> <https://debbugs.gnu.org/43830>
> 
> That's exactly why I said "with modifiers": that bug report is about
> C-s and the likes.  By contrast, when the keyboard language is
> switched, you do NOT want the s/ы key to generate s instead of ы.

Consider "C-s" `isearch-forward' followed by "M-s i" 
`isearch-toggle-invisible': "C-ы M-ы ш" with bare "ш" should work as 
"C-s M-s i" but "ш" bound to `self-insert-command' should insert "ш".

Taking into account which way some applications are localized, perhaps 
there are users who rarely switched to a Latin (e.g. US) keyboard 
layout. E.g. spreadsheets may have translated function names, not to 
mention accelerator keys.

There should be a way to specify whether symbol is from the base (Latin) 
keyboard layout or from localized one. E.g. "," and some other 
punctuation characters are jumping. Perhaps it may be achieved by 
additional virtual modifier: "L-," should be matched against localized 
layout. However user may have multiple non-Latin layouts configured and 
GNOME reconfigures XKB on each layout switch to 2 groups: Latin and 
current one.

Re: Physical keyboard events

[Cecilio Pardo]

On 29/10/2024 17:55, Yuri Khan wrote:
>> I meant the non-modifier keys.  When some OS feature redefines a key,
>> low-level events will not know that, and will still consider the key
>> labeled 'a' as 'a', even though I might have switched the keyboard to
>> another language, where the key labeled 'a' actually produces a
>> completely different character, say, 'ש'.
> 
>  From where I stand, that would be a feature, in some carefully chosen
> cases. When I’m switched to a layout where the ‘a’ key produces an ‘ф’
> character, or an ‘α’, or a ち, I’d still want Ctrl+this key to behave
> as C-a.

Probably we can implement this.

Re: Physical keyboard events

[Cecilio Pardo]

On 29/10/2024 17:44, Eli Zaretskii wrote:

>> Thats why the events will be bound in special-event-map. Nobody will see
>> them, except for the code that handles them.  We can of course
>> completely disable them with a variable.
> 
> Even if no one sees them, bombarding the Emacs event queue with
> useless events will have its effect: Emacs will become more sluggish,
> some while-no-input loops will unexpectedly exit just because the user
> happened to touch the Shift key for some reason, etc.

This should then be always disabled by default, and explain the price to 
pay to those who want it.  I find it acceptable.

>>> Physical keys also raise the issue of supporting input methods,
>>> keyboard layout switches, etc.
>>
>> I will define a list of keys: LeftShit, RightShift, LeftControl, etc.
>> The platform dependent code will decide which one was pressed. As events
>> will be invisible, I don't think we will interfere with input methods.
> 
> I meant the non-modifier keys.  When some OS feature redefines a key,
> low-level events will not know that, and will still consider the key
> labeled 'a' as 'a', even though I might have switched the keyboard to
> another language, where the key labeled 'a' actually produces a
> completely different character, say, 'ש'.

The use cases I have in mind are with modifiers.  If others appear, it 
should be clear to the user that she need to bind the key by what the OS 
sends when she presses it.

>>> However, on what systems and which Emacs configurations will it be
>>> possible to provide such a feature?
>>
>> I think all GUI systems can use this.
> 
> So X (with or without any toolkit we support), PGTK, MS-Windows, and
> macOS -- all those let applications access low-level key events?

I would not call it low level. On Windows, it would WM_KEYDOWN and 
VM_KEYUP. And we would use the 'virtual key', not the scan code.

Re: Physical keyboard events

[Alan Mackenzie]

Hello, Cecilio.

On Tue, Oct 29, 2024 at 00:15:22 +0100, Cecilio Pardo wrote:
> Hello,

> I'm planning to implement physical key press/release events for emacs.
> I would add a new element to 'enum event_kind', that in turn would
> send a new input event. This input event will be bound in
> 'special-event-map' so that it will not modify the normal flow of
> keyboard input. Platform dependent code would send these events
> on key press and release.

> Then a lisp fuction can be bound to this on the special-event-map, to
> implement the detection of:

> - double/triple tap on Shift, Control, Alt, etc
> - Long presses on Shift, Control, Alt, etc.

I envisage these leading to trouble.

For example, my KVM box intercepts a sufficiently rapid double press on
(either) Control key, and then expects a CR to switch computers, or ESC
to cancel (and maybe there are other keys I don't know about).

I quite frequently start typing a command by pressing the Control key,
then change my mind and let it go again.  I might sometimes hold that
key while trying to decide what I want to do.  The same surely applies
to Meta as well.

To make this work on a tty would involve fancy work on the keyboard
layout if it's even possible.  On a Linux console, it might even need
enhancements to the kernel.

I'm not sure binding our shift keys to commands, or even prefixes, is a
good idea.

> This actions could be bound to commands, or could add a modififer
> (Super, Hyper) to next commands.

> And make Tetris independent of the keyboard repeat rate :)

> Has something like this been discussed before, so I can check?

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Physical keyboard events

[Cecilio Pardo]

On 29/10/2024 18:13, Alan Mackenzie wrote:

> I envisage these leading to trouble.
> 
> For example, my KVM box intercepts a sufficiently rapid double press on
> (either) Control key, and then expects a CR to switch computers, or ESC
> to cancel (and maybe there are other keys I don't know about).
> 
> I quite frequently start typing a command by pressing the Control key,
> then change my mind and let it go again.  I might sometimes hold that
> key while trying to decide what I want to do.  The same surely applies
> to Meta as well.

The way I hope to implement it, there will be no interference if you 
don't activate it. Many editors such as VSCode and the ones from 
JetBrains use this, and people appreciate it.

> To make this work on a tty would involve fancy work on the keyboard
> layout if it's even possible.  On a Linux console, it might even need
> enhancements to the kernel.
> 
> I'm not sure binding our shift keys to commands, or even prefixes, is a
> good idea.

I was planning for GUI systems alone.

Thanks.

Re: Physical keyboard events

[Alan Mackenzie]

Hello, Cecilio.

On Tue, Oct 29, 2024 at 19:20:43 +0100, Cecilio Pardo wrote:
> On 29/10/2024 18:13, Alan Mackenzie wrote:

> > I envisage these leading to trouble.

> > For example, my KVM box intercepts a sufficiently rapid double press on
> > (either) Control key, and then expects a CR to switch computers, or ESC
> > to cancel (and maybe there are other keys I don't know about).

> > I quite frequently start typing a command by pressing the Control key,
> > then change my mind and let it go again.  I might sometimes hold that
> > key while trying to decide what I want to do.  The same surely applies
> > to Meta as well.

> The way I hope to implement it, there will be no interference if you 
> don't activate it. Many editors such as VSCode and the ones from 
> JetBrains use this, and people appreciate it.

Somebody not activating it will not have access to the commands which
other people assign to these new key combinations.  That could be a
problem.

> > To make this work on a tty would involve fancy work on the keyboard
> > layout if it's even possible.  On a Linux console, it might even need
> > enhancements to the kernel.

> > I'm not sure binding our shift keys to commands, or even prefixes, is a
> > good idea.

> I was planning for GUI systems alone.

That's a very un-Emacs like thing to do.  Apart from specifically
graphicky things, the convention is that features are available
regardless of whether on a GUI or a TUI.  For this reason, bindings like
C-<up> are frowned upon, although they are used in some places (hello,
Org!).

> Thanks.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Physical keyboard events

[Cecilio Pardo]

On 29/10/2024 20:31, Alan Mackenzie wrote:

>> The way I hope to implement it, there will be no interference if you
>> don't activate it. Many editors such as VSCode and the ones from
>> JetBrains use this, and people appreciate it.
> 
> Somebody not activating it will not have access to the commands which
> other people assign to these new key combinations.  That could be a
> problem.

This bindings would be reserved for the user, not for packages default 
bindings. Of course, we can't control what packages do.

>> I was planning for GUI systems alone.
> 
> That's a very un-Emacs like thing to do.  Apart from specifically
> graphicky things, the convention is that features are available
> regardless of whether on a GUI or a TUI.  For this reason, bindings like
> C-<up> are frowned upon, although they are used in some places (hello,
> Org!).

It is practically imposible to do it on ttys, I think.

I wish I could implement this in lisp, or as a module, but that is not 
possible. Can only be implemented modifying emacs core.

This is almost a toy thing, so I'll leave it as there is disagreement.

Thanks for your time.

Re: Physical keyboard events

[Yuri Khan]

On Wed, 30 Oct 2024 at 04:46, Cecilio Pardo <cpardo@imayhem.com> wrote:

> > That's a very un-Emacs like thing to do.  Apart from specifically
> > graphicky things, the convention is that features are available
> > regardless of whether on a GUI or a TUI.  For this reason, bindings like
> > C-<up> are frowned upon, although they are used in some places (hello,
> > Org!).
>
> It is practically imposible to do it on ttys, I think.

Look into modern terminal emulators such as kitty, wezterm, and
several others implementing an advanced keyboard protocol.

https://sw.kovidgoyal.net/kitty/keyboard-protocol/

Re: Physical keyboard events

[Eli Zaretskii]

> From: Yuri Khan <yuri.v.khan@gmail.com>
> Date: Wed, 30 Oct 2024 13:02:22 +0700
> Cc: Alan Mackenzie <acm@muc.de>, emacs-devel@gnu.org
> 
> On Wed, 30 Oct 2024 at 04:46, Cecilio Pardo <cpardo@imayhem.com> wrote:
> 
> > > That's a very un-Emacs like thing to do.  Apart from specifically
> > > graphicky things, the convention is that features are available
> > > regardless of whether on a GUI or a TUI.  For this reason, bindings like
> > > C-<up> are frowned upon, although they are used in some places (hello,
> > > Org!).
> >
> > It is practically imposible to do it on ttys, I think.
> 
> Look into modern terminal emulators such as kitty, wezterm, and
> several others implementing an advanced keyboard protocol.

We want to be able to use this on consoles, if possible, not just on
terminal emulators (which are really GUI programs in disguise).

Re: Physical keyboard events

[Yuri Khan]

On Wed, 30 Oct 2024 at 22:23, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Yuri Khan <yuri.v.khan@gmail.com>
> > Look into modern terminal emulators such as kitty, wezterm, and
> > several others implementing an advanced keyboard protocol.
>
> We want to be able to use this on consoles, if possible, not just on
> terminal emulators (which are really GUI programs in disguise).

You said it yourself that we don’t confine features to the lowest
common denominator.

Re: Physical keyboard events

[Eli Zaretskii]

> From: Yuri Khan <yuri.v.khan@gmail.com>
> Date: Wed, 30 Oct 2024 23:51:36 +0700
> Cc: cpardo@imayhem.com, acm@muc.de, emacs-devel@gnu.org
> 
> On Wed, 30 Oct 2024 at 22:23, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > > From: Yuri Khan <yuri.v.khan@gmail.com>
> > > Look into modern terminal emulators such as kitty, wezterm, and
> > > several others implementing an advanced keyboard protocol.
> >
> > We want to be able to use this on consoles, if possible, not just on
> > terminal emulators (which are really GUI programs in disguise).
> 
> You said it yourself that we don’t confine features to the lowest
> common denominator.

Which is why I think we should not try doing this on TTYs at all.

Re: Physical keyboard events

[Eli Zaretskii]

> Date: Tue, 29 Oct 2024 19:31:02 +0000
> Cc: emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > I was planning for GUI systems alone.
> 
> That's a very un-Emacs like thing to do.  Apart from specifically
> graphicky things, the convention is that features are available
> regardless of whether on a GUI or a TUI.  For this reason, bindings like
> C-<up> are frowned upon, although they are used in some places (hello,
> Org!).

Since we already have various keyboard-related features that don't
work on text-mode terminals, I see no reason to object to another one.
Eventually, an idea that Emacs should not have any features that
cannot be had on TTY is an idea that will keep Emacs from acquiring
very useful features.  Our policy should be (and is, AFAIK) that we
provide on TTY everything we can, but do not reject features which
cannot work on TTYs.