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.

Re: Physical keyboard events

[Cecilio Pardo]

[-- Attachment #1: Type: text/plain, Size: 1703 bytes --]

Hello,

This is my proposal as a draft patch.  It allows to detect double (or
triple) tap on shift, control, alt keys (left or right), and bind
commands to those.  Also can add Hyper modifier to next key.

- The change in emacs core (keyboard.c) is to define a new event
   'physical-key.  That event is bound to 'ignore on special-event-map,
   so will not interfere with anything, unless rebound.
- Then, particular term implementations add these events when
   needed.  The patch includes that for X, PGTK and ms-windows. Only
   rshift, lshift, lctrl, etc. generate events.  We could add a
   variable to completely disable this if required.
- Finally, the function physkey-init in physkey.el rebinds the event
   to physkey-handle.  Bindings for n-tap of the keys can be added with
   physkey-bind.  One can bind functions, commands, or the 'hyper symbol
   to add hyper modifier to the next key.

I made a bad choice by using the word 'physical'.  This is using key
identification provided by the OS input system, so no scan codes or
raw data.

I also think it is unobstrusive to those who don't want this.

And some related use cases that may be interesting, or not.

- Cycling over something with a key like C-tab, and only really
   selecting when releasing C, like the window cycling with Alt+Tab,
   which cycles trough thumbnails until your release Alt, and lets you
   cancel by pressing Esc.
- Better support for key-chords,
   https://github.com/emacsorphanage/key-chord
- MacOS style holding key to get accented version of character.
- Stenography input with standard keyboards.
- Feature request: Add support for key release event
   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=22163

[-- Attachment #2: 0001-Add-events-for-key-press-and-key-release-on-gui-syst.patch --]
[-- Type: text/plain, Size: 12278 bytes --]

From fbd9b1da821634f0288327c8924bec9fd9960aa0 Mon Sep 17 00:00:00 2001
From: Cecilio Pardo <cpardo@imayhem.com>
Date: Mon, 28 Oct 2024 23:57:35 +0100
Subject: [PATCH] Add events for key press and key release on gui systems.

And detection of double/triple taps on modifier keys.
---
 lisp/physkey.el | 83 +++++++++++++++++++++++++++++++++++++++++++++++++
 src/keyboard.c  | 21 +++++++++++++
 src/pgtkterm.c  | 34 ++++++++++++++++++++
 src/termhooks.h |  1 +
 src/w32fns.c    |  5 +++
 src/w32term.c   | 38 ++++++++++++++++++++++
 src/w32term.h   |  3 +-
 src/xterm.c     | 39 +++++++++++++++++++++++
 8 files changed, 223 insertions(+), 1 deletion(-)
 create mode 100644 lisp/physkey.el

diff --git a/lisp/physkey.el b/lisp/physkey.el
new file mode 100644
index 00000000000..5dd3f81d685
--- /dev/null
+++ b/lisp/physkey.el
@@ -0,0 +1,83 @@
+;;; -*- lexical-binding: t -*-
+(require 'cl-lib)
+
+;; User options
+(defvar physkey-tap-timeout 1000)
+(defvar physkey-tap-count 2)
+(defvar physkey-tap-keys
+  '(lshift rshift lctrl rctrl lalt ralt))
+(defvar physkey-bindings nil)
+
+(defun physkey-init ()
+  (interactive)
+  (define-key special-event-map [physical-key] 'physkey-handle)
+  (setq physkey-bindings nil)
+  (physkey-bind 'tap 'lshift 'delete-other-windows)
+  (physkey-bind 'tap 'lctrl 'hyper))
+
+;; For example:
+;; (physkey-add-binding 'tap 'lshift 'delete-other-windows)
+;; Can bind to a command, a function or the symbol 'hyper.
+(defun physkey-bind (action key function)
+  (push (list action key function) physkey-bindings))
+
+;; We store the last events here to test for multitap.
+(defvar physkey-events nil)
+
+;; If positive, return key ('lshift, etc) else return nil.
+(defun physkey-detect-n-tap (n timeout)
+  ;; The physical-key event is like this:
+  ;; (physical-key t lshift 90196265 #<frame>)
+  ;; The second element is t for a key press, nil for a key release
+  ;; The fourth element is the time in milliseconds
+  ;; The fifth is the frame, we don't use it yet.
+
+  (let ((key (cl-third last-input-event)))
+    (if (not (member key physkey-tap-keys))
+        ;; Key not in tap list, clear history
+        (setq physkey-events nil)
+      ;; Clear it also if the first element is from a different key
+      (and physkey-events
+           (not (equal (cl-third (car physkey-events)) key))
+           (setq physkey-events nil))
+      (push last-input-event physkey-events)
+      ;; Only care about last 2xN events
+      (ntake (* 2 n) physkey-events)
+      ;; If we have:
+      ;; - Exactly 2 * n events.
+      ;; - down, up, down, up, ...
+      ;; - not two much time between first and last
+      (and (eq (* 2 n) (length physkey-events))
+           (cl-every 'eq
+                     (ntake (* 2 n)
+                            (list nil t nil t nil t nil t
+                                  nil t nil t nil t nil t))
+                     (mapcar 'cl-second physkey-events))
+           (< (- (cl-fourth (cl-first physkey-events))
+                 (cl-fourth (car (last physkey-events))))
+              timeout)
+           (progn
+             (setq physkey-events nil)
+             key)))))
+
+(defun physkey-handle ()
+  (interactive)
+  (let ((tap-key (physkey-detect-n-tap
+                  physkey-tap-count
+                  physkey-tap-timeout)))
+    (when tap-key
+      (let ((func (cl-third
+                   (seq-find
+                    (lambda (b)
+                      (and (eq (cl-first b) 'tap)
+                           (eq (cl-second b) tap-key)))
+                    physkey-bindings))))
+        (cond
+         ((commandp func) (call-interactively func))
+         ((functionp func) (funcall func))
+         ((eq 'hyper func)
+          (message "H-...")
+          (let ((r (read-event)))
+            (setq unread-command-events
+                  (list (event-apply-modifier
+                         r 'hyper 24 "H-"))))))))))
diff --git a/src/keyboard.c b/src/keyboard.c
index 6d28dca9aeb..4c24e3c8bd3 100644
--- a/src/keyboard.c
+++ b/src/keyboard.c
@@ -4274,6 +4274,7 @@ kbd_buffer_get_event (KBOARD **kbp,
       case CONFIG_CHANGED_EVENT:
       case FOCUS_OUT_EVENT:
       case SELECT_WINDOW_EVENT:
+      case PHYSICAL_KEY_EVENT:
         {
           obj = make_lispy_event (&event->ie);
           kbd_fetch_ptr = next_kbd_event (event);
@@ -7118,6 +7119,14 @@ make_lispy_event (struct input_event *event)
     case PREEDIT_TEXT_EVENT:
       return list2 (Qpreedit_text, event->arg);
 
+    case PHYSICAL_KEY_EVENT:
+      return listn (5,
+		    Qphysical_key,
+		    XCAR (event->arg), /* Press or release.  */
+		    XCAR (XCDR (event->arg)), /* The key symbol.  */
+		    make_fixnum (event->timestamp),
+		    event->frame_or_window);
+
       /* The 'kind' field of the event is something we don't recognize.  */
     default:
       emacs_abort ();
@@ -12931,6 +12940,14 @@ syms_of_keyboard (void)
   DEFSYM (Qfile_notify, "file-notify");
 #endif /* USE_FILE_NOTIFY */
 
+  DEFSYM (Qphysical_key, "physical-key");
+  DEFSYM (Qlshift, "lshift");
+  DEFSYM (Qrshift, "rshift");
+  DEFSYM (Qlctrl, "lctrl");
+  DEFSYM (Qrctrl, "rctrl");
+  DEFSYM (Qlalt, "lalt");
+  DEFSYM (Qralt, "ralt");
+
   DEFSYM (Qtouch_end, "touch-end");
 
   /* Menu and tool bar item parts.  */
@@ -14018,6 +14035,10 @@ keys_of_keyboard (void)
 			    "handle-focus-out");
   initial_define_lispy_key (Vspecial_event_map, "move-frame",
 			    "handle-move-frame");
+  initial_define_lispy_key (Vspecial_event_map, "physical-key",
+			    "ignore");
+
+
 }
 
 /* Mark the pointers in the kboard objects.
diff --git a/src/pgtkterm.c b/src/pgtkterm.c
index 079945126e0..f4ade6c9f1c 100644
--- a/src/pgtkterm.c
+++ b/src/pgtkterm.c
@@ -5201,6 +5201,36 @@ pgtk_enqueue_preedit (struct frame *f, Lisp_Object preedit)
   evq_enqueue (&inev);
 }
 
+static void
+pgtk_maybe_send_physical_key_event (GdkEvent *event)
+{
+  Lisp_Object key;
+  switch (event->key.keyval)
+    {
+    case GDK_KEY_Shift_L: key = Qlshift; break;
+    case GDK_KEY_Shift_R: key = Qrshift; break;
+    case GDK_KEY_Control_L: key = Qlctrl; break;
+    case GDK_KEY_Control_R: key = Qrctrl; break;
+    case GDK_KEY_Alt_L: key = Qlalt; break;
+    case GDK_KEY_Alt_R: key = Qralt; break;
+    default:
+      return;
+    }
+  bool keypress = event->key.type == GDK_KEY_PRESS;
+  struct frame *f = pgtk_any_window_to_frame (event->key.window);
+  if (!f)
+    return;
+
+  union buffered_input_event inev;
+
+  EVENT_INIT (inev.ie);
+  XSETFRAME (inev.ie.frame_or_window, f);
+  inev.ie.kind = PHYSICAL_KEY_EVENT;
+  inev.ie.timestamp = event->key.time;
+  inev.ie.arg = list2 (keypress ? Qt : Qnil, key);
+  evq_enqueue (&inev);
+}
+
 static gboolean
 key_press_event (GtkWidget *widget, GdkEvent *event, gpointer *user_data)
 {
@@ -5210,6 +5240,8 @@ key_press_event (GtkWidget *widget, GdkEvent *event, gpointer *user_data)
   struct frame *f;
   struct pgtk_display_info *dpyinfo;
 
+  pgtk_maybe_send_physical_key_event(event);
+
   f = pgtk_any_window_to_frame (gtk_widget_get_window (widget));
   EVENT_INIT (inev.ie);
   hlinfo = MOUSE_HL_INFO (f);
@@ -5454,6 +5486,8 @@ key_release_event (GtkWidget *widget,
   GdkDisplay *display;
   struct pgtk_display_info *dpyinfo;
 
+  pgtk_maybe_send_physical_key_event(event);
+
   display = gtk_widget_get_display (widget);
   dpyinfo = pgtk_display_info_for_display (display);
 
diff --git a/src/termhooks.h b/src/termhooks.h
index d6a9300bac9..f03b6126a53 100644
--- a/src/termhooks.h
+++ b/src/termhooks.h
@@ -347,6 +347,7 @@ #define EMACS_TERMHOOKS_H
   /* In a NOTIFICATION_EVENT, .arg is a lambda to evaluate.  */
   , NOTIFICATION_EVENT
 #endif /* HAVE_ANDROID */
+  , PHYSICAL_KEY_EVENT
 };
 
 /* Bit width of an enum event_kind tag at the start of structs and unions.  */
diff --git a/src/w32fns.c b/src/w32fns.c
index eb42d3b61b2..ef98f2db7e7 100644
--- a/src/w32fns.c
+++ b/src/w32fns.c
@@ -4650,6 +4650,8 @@ w32_wnd_proc (HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
     case WM_KEYUP:
     case WM_SYSKEYUP:
       record_keyup (wParam, lParam);
+      signal_user_input ();
+      my_post_msg( &wmsg, hwnd, WM_EMACS_PHYSICAL_KEY, wParam, lParam );
       goto dflt;
 
     case WM_KEYDOWN:
@@ -4676,6 +4678,9 @@ w32_wnd_proc (HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
       if (w32_use_fallback_wm_chars_method)
 	wParam = map_keypad_keys (wParam, (lParam & 0x1000000L) != 0);
 
+      signal_user_input ();
+      my_post_msg( &wmsg, hwnd, WM_EMACS_PHYSICAL_KEY, wParam, lParam );
+
       windows_translate = 0;
 
       switch (wParam)
diff --git a/src/w32term.c b/src/w32term.c
index 88622700386..c58391d4897 100644
--- a/src/w32term.c
+++ b/src/w32term.c
@@ -5230,6 +5230,44 @@ w32_read_socket (struct terminal *terminal,
 	    }
 	  break;
 
+	case WM_EMACS_PHYSICAL_KEY:
+	  WORD key_flags = HIWORD (msg.msg.lParam);
+	  BOOL is_wm_keyup = key_flags & KF_UP;
+
+	  if (is_wm_keyup || (key_flags & KF_REPEAT) == 0) /* WM_KEYDOWN, not repeating.  */
+	    {
+	      WORD scan_code = LOBYTE (key_flags);
+	      if (key_flags & KF_EXTENDED)
+		scan_code = MAKEWORD (scan_code, 0xE0);
+
+	      UINT translated = MapVirtualKey (scan_code, MAPVK_VSC_TO_VK_EX);
+	      WORD vk = LOWORD (msg.msg.wParam);
+	      if (translated)
+		vk = LOWORD (translated);
+
+	      Lisp_Object key = Qnil;
+
+	      switch (vk)
+		{
+		case VK_LSHIFT: key = Qlshift; break;
+		case VK_RSHIFT: key = Qrshift; break;
+		case VK_LCONTROL: key = Qlctrl; break;
+		case VK_RCONTROL: key = Qrctrl; break;
+		case VK_LMENU: key = Qlalt; break;
+		case VK_RMENU: key = Qralt; break;
+		}
+
+	      if (!NILP (key))
+		{
+		  f = w32_window_to_frame (dpyinfo, msg.msg.hwnd);
+		  inev.kind = PHYSICAL_KEY_EVENT;
+		  XSETFRAME (inev.frame_or_window, f);
+		  inev.timestamp = msg.msg.time;
+		  inev.arg = list2 (is_wm_keyup ? Qnil : Qt, key);
+		}
+	    }
+	  break;
+
         case WM_UNICHAR:
 	case WM_SYSCHAR:
 	case WM_CHAR:
diff --git a/src/w32term.h b/src/w32term.h
index cad9fcf8cb1..24fdf5421f8 100644
--- a/src/w32term.h
+++ b/src/w32term.h
@@ -713,7 +713,8 @@ #define WM_EMACS_FILENOTIFY            (WM_EMACS_START + 25)
 #define WM_EMACS_IME_STATUS            (WM_EMACS_START + 26)
 #define WM_EMACS_DRAGOVER              (WM_EMACS_START + 27)
 #define WM_EMACS_DROP                  (WM_EMACS_START + 28)
-#define WM_EMACS_END                   (WM_EMACS_START + 29)
+#define WM_EMACS_PHYSICAL_KEY          (WM_EMACS_START + 29)
+#define WM_EMACS_END                   (WM_EMACS_START + 30)
 
 #define WND_FONTWIDTH_INDEX    (0)
 #define WND_LINEHEIGHT_INDEX   (4)
diff --git a/src/xterm.c b/src/xterm.c
index 0c20d38b0f7..210c5a9ef50 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -17840,6 +17840,43 @@ #define STORE_KEYSYM_FOR_DEBUG(keysym) ((void)0)
 
 static struct x_display_info *next_noop_dpyinfo;
 
+static void
+x_maybe_send_physical_key_event (struct x_display_info *dpyinfo, XEvent *event)
+{
+#ifdef HAVE_XKB
+  if (event->type != KeyPress && event->type != KeyRelease)
+    return;
+  bool keypress = (event->type == KeyPress);
+  KeySym keysym = XkbKeycodeToKeysym (dpyinfo->display, event->xkey.keycode,
+				      0, 0 );
+  Lisp_Object key;
+  switch (keysym)
+    {
+    case XK_Shift_L: key = Qlshift; break;
+    case XK_Shift_R: key = Qrshift; break;
+    case XK_Control_L: key = Qlctrl; break;
+    case XK_Control_R: key = Qrctrl; break;
+    case XK_Alt_L: key = Qlalt; break;
+    case XK_Alt_R: key = Qralt; break;
+    default:
+      return;
+    }
+
+  struct frame *f = x_any_window_to_frame (dpyinfo, event->xkey.window);
+  if (!f)
+    return;
+
+  struct input_event ie;
+
+  EVENT_INIT (ie);
+  XSETFRAME (ie.frame_or_window, f);
+  ie.kind = PHYSICAL_KEY_EVENT;
+  ie.timestamp = event->xkey.time;
+  ie.arg = list2 (keypress ? Qt : Qnil, key);
+  kbd_buffer_store_event (&ie);
+#endif
+}
+
 /* Filter events for the current X input method.
    DPYINFO is the display this event is for.
    EVENT is the X event to filter.
@@ -17859,6 +17896,8 @@ x_filter_event (struct x_display_info *dpyinfo, XEvent *event)
 
   struct frame *f1;
 
+  x_maybe_send_physical_key_event (dpyinfo, event);
+
 #if defined HAVE_XINPUT2 && defined USE_GTK
   bool xinput_event = false;
   if (dpyinfo->supports_xi2
-- 
2.35.1.windows.2

Re: Physical keyboard events

[Po Lu]

Cecilio Pardo <cpardo@imayhem.com> writes:

> +static void
> +x_maybe_send_physical_key_event (struct x_display_info *dpyinfo, XEvent *event)
> +{
> +#ifdef HAVE_XKB

Thank you.  A number of comments: this is simply unacceptable, as Emacs
must not depend on XKB for such a basic feature.

> +  if (event->type != KeyPress && event->type != KeyRelease)
> +    return;
> +  bool keypress = (event->type == KeyPress);
> +  KeySym keysym = XkbKeycodeToKeysym (dpyinfo->display, event->xkey.keycode,
> +				      0, 0 );
> +  Lisp_Object key;
> +  switch (keysym)
> +    {
> +    case XK_Shift_L: key = Qlshift; break;
> +    case XK_Shift_R: key = Qrshift; break;
> +    case XK_Control_L: key = Qlctrl; break;
> +    case XK_Control_R: key = Qrctrl; break;
> +    case XK_Alt_L: key = Qlalt; break;
> +    case XK_Alt_R: key = Qralt; break;
> +    default:
> +      return;
> +    }

??? Code producing such events should not relay modifier keysyms
verbatim, but ought to detect the virtual modifiers to which they are
mapped, and convert them into Emacs modifiers, namely, meta, alt, ctrl,
hyper, super, and shift.  Otherwise, Lisp will find it impossible
reliably to establish a correspondence between "physical key events" and
modifiers.

> +  struct frame *f = x_any_window_to_frame (dpyinfo, event->xkey.window);
> +  if (!f)
> +    return;
> +
> +  struct input_event ie;
> +
> +  EVENT_INIT (ie);
> +  XSETFRAME (ie.frame_or_window, f);
> +  ie.kind = PHYSICAL_KEY_EVENT;
> +  ie.timestamp = event->xkey.time;
> +  ie.arg = list2 (keypress ? Qt : Qnil, key);
> +  kbd_buffer_store_event (&ie);
> +#endif
> +}

Please find some means of generating such events by saving them into the
keyboard event buffer defined in handle_ome_xevent.

>  /* Filter events for the current X input method.
>     DPYINFO is the display this event is for.
>     EVENT is the X event to filter.
> @@ -17859,6 +17896,8 @@ x_filter_event (struct x_display_info *dpyinfo, XEvent *event)
>  
>    struct frame *f1;
>  
> +  x_maybe_send_physical_key_event (dpyinfo, event);
> +
>  #if defined HAVE_XINPUT2 && defined USE_GTK
>    bool xinput_event = false;
>    if (dpyinfo->supports_xi2

x_filter_events is not the proper location for this call.  It is only
invoked to filter an event through the active GTK or X input method
context, and it is not invoked if Emacs is configured not to open input
method contexts, or they are unavailable by happenstance.

This call is properly placed in handle_one_xevent, beneath the labels
for KeyPress, KeyRelease, XI_KeyPress, XI_KeyRelease, and the GTK
keyboard callbacks in gtkutil.c.  Pay attention to the different manners
in which the key codes are converted into keysyms and the keysyms into
modifiers, and imitate them closely or reuse them if possible.

Lastly, you must decide whether to capture modifier key events before
they are filtered by the input method, or after.  Input methods have
complete discretion over disposing of these events and will either
discard them entirely or resend a possibly modified event to Emacs.  In
the latter scenario, you will receive duplicates of one and the same
event, and in principle it is impossible to distinguish between the
duplicates and the originals.  Equally unsatisfactory is the option of
generating these events after they are filtered by the input method,
since none will be generated if the IM takes the other course.

These are the same concerns that led me not to implement raw modifier
key events when this feature was proposed some years ago.

Re: Physical keyboard events

[Cecilio Pardo]

On 04/11/2024 1:21, Po Lu wrote:

> Thank you.  A number of comments: this is simply unacceptable, as Emacs
> must not depend on XKB for such a basic feature.

Ok.

> ??? Code producing such events should not relay modifier keysyms
> verbatim, but ought to detect the virtual modifiers to which they are
> mapped, and convert them into Emacs modifiers, namely, meta, alt, ctrl,
> hyper, super, and shift.  Otherwise, Lisp will find it impossible
> reliably to establish a correspondence between "physical key events" and
> modifiers.

This is about keys, not modifiers. For the use case of binding commands 
to keys, this remapping would be counterproductive. I can provide a 
function to make that conversion if needed.


> Please find some means of generating such events by saving them into the
> keyboard event buffer defined in handle_ome_xevent.

Ok.

> x_filter_events is not the proper location for this call.  It is only
> invoked to filter an event through the active GTK or X input method
> context, and it is not invoked if Emacs is configured not to open input
> method contexts, or they are unavailable by happenstance.
> 
> This call is properly placed in handle_one_xevent, beneath the labels
> for KeyPress, KeyRelease, XI_KeyPress, XI_KeyRelease, and the GTK
> keyboard callbacks in gtkutil.c.  Pay attention to the different manners
> in which the key codes are converted into keysyms and the keysyms into
> modifiers, and imitate them closely or reuse them if possible.
> 
> Lastly, you must decide whether to capture modifier key events before
> they are filtered by the input method, or after.  Input methods have
> complete discretion over disposing of these events and will either
> discard them entirely or resend a possibly modified event to Emacs.  In
> the latter scenario, you will receive duplicates of one and the same
> event, and in principle it is impossible to distinguish between the
> duplicates and the originals.  Equally unsatisfactory is the option of
> generating these events after they are filtered by the input method,
> since none will be generated if the IM takes the other course.
> 
> These are the same concerns that led me not to implement raw modifier
> key events when this feature was proposed some years ago.

Then probably this should only support X11+gtk and pgtk. Do those look 
ok? Is it acceptable to have support for nonfree systems in this case?

Thanks for your review.

Re: Physical keyboard events

[Po Lu]

Cecilio Pardo <cpardo@imayhem.com> writes:

> On 04/11/2024 1:21, Po Lu wrote:
>
>> Thank you.  A number of comments: this is simply unacceptable, as Emacs
>> must not depend on XKB for such a basic feature.
>
> Ok.
>
>> ??? Code producing such events should not relay modifier keysyms
>> verbatim, but ought to detect the virtual modifiers to which they are
>> mapped, and convert them into Emacs modifiers, namely, meta, alt, ctrl,
>> hyper, super, and shift.  Otherwise, Lisp will find it impossible
>> reliably to establish a correspondence between "physical key events" and
>> modifiers.
>
> This is about keys, not modifiers. For the use case of binding
> commands to keys, this remapping would be counterproductive. I can
> provide a function to make that conversion if needed.

I must disagree.  When Emacs has enough information to decide which
modifiers are produced by physical keys it receives, as it does here, it
should not confuse Lisp programmers with a view of the keyboard state
that runs contrary to their expectations, not to mention that the
disparity between X keysyms and X modifiers is very great, and users who
swap the positions of the Shift and Ctrl modifiers will not expect to
receive raw keyboard events which disregard their keyboard
configuration.

BTW, if the intention is to forward just modifier key events to Lisp,
don't let's refer to them as "physical keyboard events", but in more
specific terms.

>> Please find some means of generating such events by saving them into the
>> keyboard event buffer defined in handle_ome_xevent.
>
> Ok.
>
>> x_filter_events is not the proper location for this call.  It is only
>> invoked to filter an event through the active GTK or X input method
>> context, and it is not invoked if Emacs is configured not to open input
>> method contexts, or they are unavailable by happenstance.
>> This call is properly placed in handle_one_xevent, beneath the
>> labels
>> for KeyPress, KeyRelease, XI_KeyPress, XI_KeyRelease, and the GTK
>> keyboard callbacks in gtkutil.c.  Pay attention to the different manners
>> in which the key codes are converted into keysyms and the keysyms into
>> modifiers, and imitate them closely or reuse them if possible.
>> Lastly, you must decide whether to capture modifier key events
>> before
>> they are filtered by the input method, or after.  Input methods have
>> complete discretion over disposing of these events and will either
>> discard them entirely or resend a possibly modified event to Emacs.  In
>> the latter scenario, you will receive duplicates of one and the same
>> event, and in principle it is impossible to distinguish between the
>> duplicates and the originals.  Equally unsatisfactory is the option of
>> generating these events after they are filtered by the input method,
>> since none will be generated if the IM takes the other course.
>> These are the same concerns that led me not to implement raw
>> modifier
>> key events when this feature was proposed some years ago.
>
> Then probably this should only support X11+gtk and pgtk. Do those look
> ok? Is it acceptable to have support for nonfree systems in this case?

It's not acceptable only to support X11+GTK and PGTK, whether or not
non-free systems are also supported, because there are numerous severe
deficiencies with those configurations, and with them we are at the
mercy of an upstream that is uncooperative at best.  And above all, what
I said applies just as well to the GTK configurations.

Re: Physical keyboard events

[Cecilio Pardo]

On 04/11/2024 10:35, Po Lu wrote:
>> This is about keys, not modifiers. For the use case of binding
>> commands to keys, this remapping would be counterproductive. I can
>> provide a function to make that conversion if needed.
> 
> I must disagree.  When Emacs has enough information to decide which
> modifiers are produced by physical keys it receives, as it does here, it
> should not confuse Lisp programmers with a view of the keyboard state
> that runs contrary to their expectations, not to mention that the
> disparity between X keysyms and X modifiers is very great, and users who
> swap the positions of the Shift and Ctrl modifiers will not expect to
> receive raw keyboard events which disregard their keyboard
> configuration.
> 
> BTW, if the intention is to forward just modifier key events to Lisp,
> don't let's refer to them as "physical keyboard events", but in more
> specific terms.

The intention right now is just to allow users to bind actions to
multiple taps on shift, control and alt keys. Using these keys and not
others is just because these keys don't normally do anything when
pressed alone, not because they are modifiers. If an users'
customization or his input method(s) makes this unconvenient or
impossible, then this is not for that user, and should not use it.

Lisp programmers will not have to deal with these events unless they are
looking for them by binding in special-event-map, and replacing the
function that looks for multiple taps with something else.

Is this feature worth the changes I propose. For me it is.

I agree 'physical keyboard events' is an unfortunate phrase.

Re: Physical keyboard events

[Po Lu]

Cecilio Pardo <cpardo@imayhem.com> writes:

> The intention right now is just to allow users to bind actions to
> multiple taps on shift, control and alt keys. Using these keys and not
> others is just because these keys don't normally do anything when
> pressed alone, not because they are modifiers. If an users'
> customization or his input method(s) makes this unconvenient or
> impossible, then this is not for that user, and should not use it.

My point is that users frequently customize or exchange the positions of
these modifier keys, and it is the resultant modifiers that they expect
Emacs to report, not the keysyms, in special events or elsewhere.

> Is this feature worth the changes I propose. For me it is.

Well, for us that is contingent on whether they are implemented
properly.  A feature that is adequate for half of our users, will
confuse many of them, or with the sacrifices entailed by GTK, does not
measure up to this standard, alas.

Re: Physical keyboard events

[Cecilio Pardo]

>> Is this feature worth the changes I propose. For me it is.
> 
> Well, for us that is contingent on whether they are implemented
> properly.  A feature that is adequate for half of our users, will
> confuse many of them, or with the sacrifices entailed by GTK, does not
> measure up to this standard, alas.

Ok then.

Thanks for your time.

Re: Physical keyboard events

[Eli Zaretskii]

> Date: Mon, 4 Nov 2024 12:59:54 +0100
> Cc: emacs-devel@gnu.org
> From: Cecilio Pardo <cpardo@imayhem.com>
> 
> >> Is this feature worth the changes I propose. For me it is.
> > 
> > Well, for us that is contingent on whether they are implemented
> > properly.  A feature that is adequate for half of our users, will
> > confuse many of them, or with the sacrifices entailed by GTK, does not
> > measure up to this standard, alas.
> 
> Ok then.
> 
> Thanks for your time.

I hope you didn't take Po Lu's response as a rejection of your
proposed patch.  Given that you can incorporate his review comments
regarding the place to call x_maybe_send_physical_key_event, I see no
reason for us not to accept such a feature, once cleaned up and
properly documented.

Also, please recall that I preferred these events to be blocked
(a.k.a. "discarded") subject to a special variable, instead of being
inserted into the input queue and then ignored due to some keymap.
IOW, I'd prefer this to behave like track-mouse.

Thanks.

Re: Physical keyboard events

[Cecilio Pardo]

On 04/11/2024 14:29, Eli Zaretskii wrote:
> I hope you didn't take Po Lu's response as a rejection of your
> proposed patch.  Given that you can incorporate his review comments
> regarding the place to call x_maybe_send_physical_key_event, I see no
> reason for us not to accept such a feature, once cleaned up and
> properly documented.
> 
> Also, please recall that I preferred these events to be blocked
> (a.k.a. "discarded") subject to a special variable, instead of being
> inserted into the input queue and then ignored due to some keymap.
> IOW, I'd prefer this to behave like track-mouse.
> 
> Thanks.

I'll do that then.

Re: Physical keyboard events

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> I hope you didn't take Po Lu's response as a rejection of your
> proposed patch.

+1.

Re: Physical keyboard events

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Mon, 04 Nov 2024 19:49:32 +0800
> 
> Cecilio Pardo <cpardo@imayhem.com> writes:
> 
> > The intention right now is just to allow users to bind actions to
> > multiple taps on shift, control and alt keys. Using these keys and not
> > others is just because these keys don't normally do anything when
> > pressed alone, not because they are modifiers. If an users'
> > customization or his input method(s) makes this unconvenient or
> > impossible, then this is not for that user, and should not use it.
> 
> My point is that users frequently customize or exchange the positions of
> these modifier keys, and it is the resultant modifiers that they expect
> Emacs to report, not the keysyms, in special events or elsewhere.

They should not expect that with these physical events, IMO.

Re: Physical keyboard events

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

>> My point is that users frequently customize or exchange the positions of
>> these modifier keys, and it is the resultant modifiers that they expect
>> Emacs to report, not the keysyms, in special events or elsewhere.
>
> They should not expect that with these physical events, IMO.

Why not?  If Caps Lock and Ctrl are exchanged, why should Emacs depart
from every other program by not reporting Ctrl when the key labeled Caps
Lock is depressed?  Or, if another key than Hyper itself (which is not
to be found on PC keyboards) is configured to serve as the Hyper
modifier, surely we want it to be reported as Hyper?

The only reasonable manner of reporting these key events is reporting
the modifiers that Emacs will generate in response to them.  The other
correct approach, that of reporting X modifier bits uninterpreted,
yields physical keys that are just as meaningless (ctrl, shift, mod1,
mod2, mod3, and so forth) and with equally tenuous a relationship with
the modifiers that users expect to receive from Emacs.

Re: Physical keyboard events

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: cpardo@imayhem.com,  emacs-devel@gnu.org
> Date: Mon, 04 Nov 2024 22:09:33 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> My point is that users frequently customize or exchange the positions of
> >> these modifier keys, and it is the resultant modifiers that they expect
> >> Emacs to report, not the keysyms, in special events or elsewhere.
> >
> > They should not expect that with these physical events, IMO.
> 
> Why not?  If Caps Lock and Ctrl are exchanged, why should Emacs depart
> from every other program by not reporting Ctrl when the key labeled Caps
> Lock is depressed?

On _physical_ level, there can be no "exchange of keys".  That
exchange exists on the logical level, where Ctrl followed by A yield a
single event whose value is 1, instead of 4 events (2 keypresses and 2
releases), none of which is 1.

> Or, if another key than Hyper itself (which is not
> to be found on PC keyboards) is configured to serve as the Hyper
> modifier, surely we want it to be reported as Hyper?

Again, not on this level.

> The only reasonable manner of reporting these key events is reporting
> the modifiers that Emacs will generate in response to them.  The other
> correct approach, that of reporting X modifier bits uninterpreted,
> yields physical keys that are just as meaningless (ctrl, shift, mod1,
> mod2, mod3, and so forth) and with equally tenuous a relationship with
> the modifiers that users expect to receive from Emacs.

They are presumably not meaningless to a Lisp program which wants to
receive such events.  Or at least this is my understanding.

I can also accept that in addition we should have some intermediate
level, whereby some key translations are performed.  But then we'd
need to agree which translations are or aren't taken into
consideration.  In the above example, does Ctrl+A produce 01 decimal?
does Ctrl-[ produce ESC? what do the keys produce when the keyboard's
language is not English? etc.  And whether to perform this or not
should be controllable by Lisp.

Re: Physical keyboard events

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Po Lu <luangruo@yahoo.com>
>> Cc: cpardo@imayhem.com,  emacs-devel@gnu.org
>> Date: Mon, 04 Nov 2024 22:09:33 +0800
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> My point is that users frequently customize or exchange the positions of
>> >> these modifier keys, and it is the resultant modifiers that they expect
>> >> Emacs to report, not the keysyms, in special events or elsewhere.
>> >
>> > They should not expect that with these physical events, IMO.
>> 
>> Why not?  If Caps Lock and Ctrl are exchanged, why should Emacs depart
>> from every other program by not reporting Ctrl when the key labeled Caps
>> Lock is depressed?
>
> On _physical_ level, there can be no "exchange of keys".  That
> exchange exists on the logical level, where Ctrl followed by A yield a
> single event whose value is 1, instead of 4 events (2 keypresses and 2
> releases), none of which is 1.

No, that is configuring Caps Lock to serve as a Ctrl latch.  I'm
speaking of remapping such a key to serve as _the_ Ctrl modifier, such
that Caps_Lock+A yields an XK_Caps_Lock event that is discarded by Emacs
as a modifier key, followed by a second event whose value is, yes, ^A,
and with the Ctrl modifier bit set in its state.

>> Or, if another key than Hyper itself (which is not
>> to be found on PC keyboards) is configured to serve as the Hyper
>> modifier, surely we want it to be reported as Hyper?
>
> Again, not on this level.
>
>> The only reasonable manner of reporting these key events is reporting
>> the modifiers that Emacs will generate in response to them.  The other
>> correct approach, that of reporting X modifier bits uninterpreted,
>> yields physical keys that are just as meaningless (ctrl, shift, mod1,
>> mod2, mod3, and so forth) and with equally tenuous a relationship with
>> the modifiers that users expect to receive from Emacs.
>
> They are presumably not meaningless to a Lisp program which wants to
> receive such events.  Or at least this is my understanding.

I am interested to hear what use Lisp programs intend to make of a mod2,
mod3, mod4, and mod5, whose meanings vary wildly from one machine to the
next.  On my system, for example:

shift       Shift_L (0x32),  Shift_R (0x3e)
lock        Caps_Lock (0x42)
control     Control_L (0x25)
mod1        Alt_L (0x40),  Alt_L (0xcc),  Meta_L (0xcd)
mod2        Num_Lock (0x4d)
mod3        ISO_Level5_Shift (0xcb)
mod4        Super_L (0x85),  Super_R (0x86),  Super_L (0xce),  Hyper_L (0xcf)
mod5        ISO_Level3_Shift (0x5c)

while on another:

shift		44 57	# Left Shift, Right Shift
lock		30	# CapsLock
control		58 64	# Control
mod1		59 63	# Meta
mod2		62	# AltGraph
mod3		90	# NumLock
mod4		60	# Left Alt
mod5		65	# Compose

Without consulting the X11 modifier keymap (which is impossible from
Lisp), how should a Lisp program derive any meaning from these modifier
bits, or the keys to which they are assigned?

> I can also accept that in addition we should have some intermediate
> level, whereby some key translations are performed.  But then we'd
> need to agree which translations are or aren't taken into
> consideration.  In the above example, does Ctrl+A produce 01 decimal?
> does Ctrl-[ produce ESC? what do the keys produce when the keyboard's
> language is not English? etc.  And whether to perform this or not
> should be controllable by Lisp.

This reaches far beyond the scope of just reporting modifier activation
that is usually discarded by Emacs (and which is always reported by the
X server).

Re: Physical keyboard events

[Cecilio Pardo]

On 05/11/2024 2:31, Po Lu wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
> 
>>> From: Po Lu <luangruo@yahoo.com>
>>> Cc: cpardo@imayhem.com,  emacs-devel@gnu.org
>>> Date: Mon, 04 Nov 2024 22:09:33 +0800
>>>
>>> Eli Zaretskii <eliz@gnu.org> writes:
>>>
>>>>> My point is that users frequently customize or exchange the positions of
>>>>> these modifier keys, and it is the resultant modifiers that they expect
>>>>> Emacs to report, not the keysyms, in special events or elsewhere.
>>>>
>>>> They should not expect that with these physical events, IMO.
>>>
>>> Why not?  If Caps Lock and Ctrl are exchanged, why should Emacs depart
>>> from every other program by not reporting Ctrl when the key labeled Caps
>>> Lock is depressed?
>>
>> On _physical_ level, there can be no "exchange of keys".  That
>> exchange exists on the logical level, where Ctrl followed by A yield a
>> single event whose value is 1, instead of 4 events (2 keypresses and 2
>> releases), none of which is 1.
> 
> No, that is configuring Caps Lock to serve as a Ctrl latch.  I'm
> speaking of remapping such a key to serve as _the_ Ctrl modifier, such
> that Caps_Lock+A yields an XK_Caps_Lock event that is discarded by Emacs
> as a modifier key, followed by a second event whose value is, yes, ^A,
> and with the Ctrl modifier bit set in its state.
> 
>>> Or, if another key than Hyper itself (which is not
>>> to be found on PC keyboards) is configured to serve as the Hyper
>>> modifier, surely we want it to be reported as Hyper?
>>
>> Again, not on this level.
>>
>>> The only reasonable manner of reporting these key events is reporting
>>> the modifiers that Emacs will generate in response to them.  The other
>>> correct approach, that of reporting X modifier bits uninterpreted,
>>> yields physical keys that are just as meaningless (ctrl, shift, mod1,
>>> mod2, mod3, and so forth) and with equally tenuous a relationship with
>>> the modifiers that users expect to receive from Emacs.
>>
>> They are presumably not meaningless to a Lisp program which wants to
>> receive such events.  Or at least this is my understanding.
> 
> I am interested to hear what use Lisp programs intend to make of a mod2,
> mod3, mod4, and mod5, whose meanings vary wildly from one machine to the
> next.  On my system, for example:
> 
> shift       Shift_L (0x32),  Shift_R (0x3e)
> lock        Caps_Lock (0x42)
> control     Control_L (0x25)
> mod1        Alt_L (0x40),  Alt_L (0xcc),  Meta_L (0xcd)
> mod2        Num_Lock (0x4d)
> mod3        ISO_Level5_Shift (0xcb)
> mod4        Super_L (0x85),  Super_R (0x86),  Super_L (0xce),  Hyper_L (0xcf)
> mod5        ISO_Level3_Shift (0x5c)
> 
> while on another:
> 
> shift		44 57	# Left Shift, Right Shift
> lock		30	# CapsLock
> control		58 64	# Control
> mod1		59 63	# Meta
> mod2		62	# AltGraph
> mod3		90	# NumLock
> mod4		60	# Left Alt
> mod5		65	# Compose
> 
> Without consulting the X11 modifier keymap (which is impossible from
> Lisp), how should a Lisp program derive any meaning from these modifier
> bits, or the keys to which they are assigned?

The idea is to report Shift_L, Shift_R, Alt_L, Meta_L not shift or alt. 
Maybe those keys are mapped to modifiers, maybe not.

Re: Physical keyboard events

[Po Lu]

Cecilio Pardo <cpardo@imayhem.com> writes:

> The idea is to report Shift_L, Shift_R, Alt_L, Meta_L not shift or
> alt.  Maybe those keys are mapped to modifiers, maybe not.

And this is improper, as the keysym does not reflect the meaning of the
key.  If someone who configures XK_Caps_Lock as a Ctrl modifier presses
this key which is by all accounts Ctrl, no "physical keyboard event"
will be reported, and by the same token, Ctrl will be reported even if
it is the Caps Lock latch that is activated if their functions are
exchanged.

Re: Physical keyboard events

[Cecilio Pardo]

On 05/11/2024 10:03, Po Lu wrote:
> Cecilio Pardo <g@imayhem.com> writes:
> 
>> The idea is to report Shift_L, Shift_R, Alt_L, Meta_L not shift or
>> alt.  Maybe those keys are mapped to modifiers, maybe not.
> 
> And this is improper, as the keysym does not reflect the meaning of the
> key.  If someone who configures XK_Caps_Lock as a Ctrl modifier presses
> this key which is by all accounts Ctrl, no "physical keyboard event"
> will be reported, and by the same token, Ctrl will be reported even if
> it is the Caps Lock latch that is activated if their functions are
> exchanged.

We are implementing the ability to bind an action to the press of the 
key, regardless of its meaning as a modifier.  This way, we can take 
advantage of double keys (Shift_L, Shift_R) and give more options to the 
user.

Re: Physical keyboard events

[Po Lu]

Cecilio Pardo <cpardo@imayhem.com> writes:

> We are implementing the ability to bind an action to the press of the
> key, regardless of its meaning as a modifier.  This way, we can take
> advantage of double keys (Shift_L, Shift_R) and give more options to
> the user.

It's not a matter of giving users more choice or finer control, but of
correctness.  How will you handle the case where the key labeled Caps
Lock is, in all functional respects, Ctrl, and that labeled Ctrl serves
another purpose that renders it simply unavailable to Emacs?

But let me pose a different question: why do you need to distinguish
between left and right modifier keys?

Re: Physical keyboard events

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Tue, 05 Nov 2024 20:21:02 +0800
> 
> Cecilio Pardo <cpardo@imayhem.com> writes:
> 
> > We are implementing the ability to bind an action to the press of the
> > key, regardless of its meaning as a modifier.  This way, we can take
> > advantage of double keys (Shift_L, Shift_R) and give more options to
> > the user.
> 
> It's not a matter of giving users more choice or finer control, but of
> correctness.  How will you handle the case where the key labeled Caps
> Lock is, in all functional respects, Ctrl, and that labeled Ctrl serves
> another purpose that renders it simply unavailable to Emacs?

Who said we should handle that case in any way, except reporting the
key as CapsLock?

> But let me pose a different question: why do you need to distinguish
> between left and right modifier keys?

Because they are separate keys.

Re: Physical keyboard events

[Cecilio Pardo]

On 05/11/2024 13:21, Po Lu wrote:
> Cecilio Pardo <cpardo@imayhem.com> writes:
> 
>> We are implementing the ability to bind an action to the press of the
>> key, regardless of its meaning as a modifier.  This way, we can take
>> advantage of double keys (Shift_L, Shift_R) and give more options to
>> the user.
> 
> It's not a matter of giving users more choice or finer control, but of
> correctness.  How will you handle the case where the key labeled Caps
> Lock is, in all functional respects, Ctrl, and that labeled Ctrl serves
> another purpose that renders it simply unavailable to Emacs?

We would respond to XK_Caps_Lock by sending an event with the symbol 
'capslock, and to Control with lctrl and rctrl. If the control key is 
unavailable beacuse it serves another purpose, then user should not bind 
it to anything.

I don't think this is incorrect in any way. We are giving the user the 
ability to detect this keypresses.  It's up to the user to decide if she 
wants to do it or not.

> But let me pose a different question: why do you need to distinguish
> between left and right modifier keys?

So I can bind a different command to each one of them.

Re: Physical keyboard events

[Po Lu]

Re: Physical keyboard events

[Po Lu]

I posted this twelve hours ago, but it was truncated in transmission.

Cecilio Pardo <cpardo@imayhem.com> writes:

> We would respond to XK_Caps_Lock by sending an event with the symbol
> 'capslock, and to Control with lctrl and rctrl. If the control key is
> unavailable beacuse it serves another purpose, then user should not
> bind it to anything.

This would prevent any portable Lisp program from being written that
exercises this feature.  For example, your patch only handles Alt_L and
Alt_R, while the key _labeled_ alt on the right side of my keyboard is
mapped to ISO_Level3_Shift.  The purpose of detecting left and right
keys is defeated anyway by such rudimentary treatment of the X keyboard
system.

> I don't think this is incorrect in any way. We are giving the user the
> ability to detect this keypresses.  It's up to the user to decide if
> she wants to do it or not.

I don't agree.  Users may be completely excluded from deciding this
question if they are installing another person's Lisp, for example.

> So I can bind a different command to each one of them.

Why can't you read the modifier map _first_ (by keycode, not keysym),
before trying to distinguish between left and right keys by inference
from the keysym, or by reading the keyboard geometry if XKB is
available?  And report key events such as `meta' and `right-meta'?

Re: Physical keyboard events

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Wed, 06 Nov 2024 20:49:37 +0800
> 
> I posted this twelve hours ago, but it was truncated in transmission.
> 
> Cecilio Pardo <cpardo@imayhem.com> writes:
> 
> > We would respond to XK_Caps_Lock by sending an event with the symbol
> > 'capslock, and to Control with lctrl and rctrl. If the control key is
> > unavailable beacuse it serves another purpose, then user should not
> > bind it to anything.
> 
> This would prevent any portable Lisp program from being written that
> exercises this feature.  For example, your patch only handles Alt_L and
> Alt_R, while the key _labeled_ alt on the right side of my keyboard is
> mapped to ISO_Level3_Shift.  The purpose of detecting left and right
> keys is defeated anyway by such rudimentary treatment of the X keyboard
> system.
> 
> > I don't think this is incorrect in any way. We are giving the user the
> > ability to detect this keypresses.  It's up to the user to decide if
> > she wants to do it or not.
> 
> I don't agree.  Users may be completely excluded from deciding this
> question if they are installing another person's Lisp, for example.
> 
> > So I can bind a different command to each one of them.
> 
> Why can't you read the modifier map _first_ (by keycode, not keysym),
> before trying to distinguish between left and right keys by inference
> from the keysym, or by reading the keyboard geometry if XKB is
> available?  And report key events such as `meta' and `right-meta'?

I already said that we could have both what you want and what Cecilio
considers TRT.  Why do you keep arguing for your concept as the only
one?

Re: Physical keyboard events

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> I already said that we could have both what you want and what Cecilio
> considers TRT.  Why do you keep arguing for your concept as the only
> one?

Because the former is fatally hamstrung for many users, from whom we
will undoubtedly receive a spate of issues reporting that their modifier
keys are not producing activation events.

Re: Physical keyboard events

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: cpardo@imayhem.com,  emacs-devel@gnu.org
> Date: Thu, 07 Nov 2024 08:25:53 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I already said that we could have both what you want and what Cecilio
> > considers TRT.  Why do you keep arguing for your concept as the only
> > one?
> 
> Because the former is fatally hamstrung for many users, from whom we
> will undoubtedly receive a spate of issues reporting that their modifier
> keys are not producing activation events.

I understand what you are saying, but Cecilio and myself clearly
disagree, so why not have both abilities in Emacs (assuming that it is
possible and practical)?

Re: Physical keyboard events

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Po Lu <luangruo@yahoo.com>
>> Cc: cpardo@imayhem.com,  emacs-devel@gnu.org
>> Date: Thu, 07 Nov 2024 08:25:53 +0800
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > I already said that we could have both what you want and what Cecilio
>> > considers TRT.  Why do you keep arguing for your concept as the only
>> > one?
>> 
>> Because the former is fatally hamstrung for many users, from whom we
>> will undoubtedly receive a spate of issues reporting that their modifier
>> keys are not producing activation events.
>
> I understand what you are saying, but Cecilio and myself clearly
> disagree, so why not have both abilities in Emacs (assuming that it is
> possible and practical)?

That would be redundant, since there is no key binding inexpressible
with the events I propose that can be expressed with events generated
from keysyms.  For most users, it will be just a simple matter of
writing `meta-left' or `meta-right' rather than `alt-right', and so
forth.

Re: Physical keyboard events

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: cpardo@imayhem.com,  emacs-devel@gnu.org
> Date: Thu, 07 Nov 2024 22:36:57 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Po Lu <luangruo@yahoo.com>
> >> Cc: cpardo@imayhem.com,  emacs-devel@gnu.org
> >> Date: Thu, 07 Nov 2024 08:25:53 +0800
> >> 
> >> Eli Zaretskii <eliz@gnu.org> writes:
> >> 
> >> > I already said that we could have both what you want and what Cecilio
> >> > considers TRT.  Why do you keep arguing for your concept as the only
> >> > one?
> >> 
> >> Because the former is fatally hamstrung for many users, from whom we
> >> will undoubtedly receive a spate of issues reporting that their modifier
> >> keys are not producing activation events.
> >
> > I understand what you are saying, but Cecilio and myself clearly
> > disagree, so why not have both abilities in Emacs (assuming that it is
> > possible and practical)?
> 
> That would be redundant, since there is no key binding inexpressible
> with the events I propose that can be expressed with events generated
> from keysyms.

It isn't redundant, since it reports different events from the same
keys.

Re: Physical keyboard events

[Cecilio Pardo]

On 07/11/2024 16:47, Eli Zaretskii wrote:
>> From: Po Lu <luangruo@yahoo.com>
>> Cc: cpardo@imayhem.com,  emacs-devel@gnu.org
>> Date: Thu, 07 Nov 2024 22:36:57 +0800
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>>>> From: Po Lu <luangruo@yahoo.com>
>>>> Cc: cpardo@imayhem.com,  emacs-devel@gnu.org
>>>> Date: Thu, 07 Nov 2024 08:25:53 +0800
>>>>
>>>> Eli Zaretskii <eliz@gnu.org> writes:
>>>>
>>>>> I already said that we could have both what you want and what Cecilio
>>>>> considers TRT.  Why do you keep arguing for your concept as the only
>>>>> one?
>>>>
>>>> Because the former is fatally hamstrung for many users, from whom we
>>>> will undoubtedly receive a spate of issues reporting that their modifier
>>>> keys are not producing activation events.
>>>
>>> I understand what you are saying, but Cecilio and myself clearly
>>> disagree, so why not have both abilities in Emacs (assuming that it is
>>> possible and practical)?
>>
>> That would be redundant, since there is no key binding inexpressible
>> with the events I propose that can be expressed with events generated
>> from keysyms.
> 
> It isn't redundant, since it reports different events from the same
> keys.

What about reporting an event, but with all pieces of information?

Alt_L Meta Meta_L

The 'keysym', the 'modifier' or nil, the 'sided-modifier' with an _L 
because the keysym has an _L, or nil.

Re: Physical keyboard events

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

>> That would be redundant, since there is no key binding inexpressible
>> with the events I propose that can be expressed with events generated
>> from keysyms.
>
> It isn't redundant, since it reports different events from the same
> keys.

But ultimately it is, literally, only a difference in name that makes a
world of difference for reliability.

Re: Physical keyboard events

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: cpardo@imayhem.com,  emacs-devel@gnu.org
> Date: Tue, 05 Nov 2024 09:31:14 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > On _physical_ level, there can be no "exchange of keys".  That
> > exchange exists on the logical level, where Ctrl followed by A yield a
> > single event whose value is 1, instead of 4 events (2 keypresses and 2
> > releases), none of which is 1.
> 
> No, that is configuring Caps Lock to serve as a Ctrl latch.  I'm
> speaking of remapping such a key to serve as _the_ Ctrl modifier, such
> that Caps_Lock+A yields an XK_Caps_Lock event that is discarded by Emacs
> as a modifier key, followed by a second event whose value is, yes, ^A,
> and with the Ctrl modifier bit set in its state.

I'm talking about a program that doesn't want to see ^A, since there's
no such key.

> >> The only reasonable manner of reporting these key events is reporting
> >> the modifiers that Emacs will generate in response to them.  The other
> >> correct approach, that of reporting X modifier bits uninterpreted,
> >> yields physical keys that are just as meaningless (ctrl, shift, mod1,
> >> mod2, mod3, and so forth) and with equally tenuous a relationship with
> >> the modifiers that users expect to receive from Emacs.
> >
> > They are presumably not meaningless to a Lisp program which wants to
> > receive such events.  Or at least this is my understanding.
> 
> I am interested to hear what use Lisp programs intend to make of a mod2,
> mod3, mod4, and mod5, whose meanings vary wildly from one machine to the
> next.

A program which wants to show the pressed key, for example?

> On my system, for example:
> 
> shift       Shift_L (0x32),  Shift_R (0x3e)
> lock        Caps_Lock (0x42)
> control     Control_L (0x25)
> mod1        Alt_L (0x40),  Alt_L (0xcc),  Meta_L (0xcd)
> mod2        Num_Lock (0x4d)
> mod3        ISO_Level5_Shift (0xcb)
> mod4        Super_L (0x85),  Super_R (0x86),  Super_L (0xce),  Hyper_L (0xcf)
> mod5        ISO_Level3_Shift (0x5c)
> 
> while on another:
> 
> shift		44 57	# Left Shift, Right Shift
> lock		30	# CapsLock
> control		58 64	# Control
> mod1		59 63	# Meta
> mod2		62	# AltGraph
> mod3		90	# NumLock
> mod4		60	# Left Alt
> mod5		65	# Compose

I don't understand what this means, sorry.  (You seem to be too deep
in the particulars of the X keyboard handling.)  I never said anything
about mod1 etc.

> Without consulting the X11 modifier keymap (which is impossible from
> Lisp), how should a Lisp program derive any meaning from these modifier
> bits, or the keys to which they are assigned?

I don't know.  I didn't write the patch.  All I'm saying is that if
the key is labeled Alt, I can envision some Lisp programs which will
want to know the key pressed was Alt, not Meta.

> > I can also accept that in addition we should have some intermediate
> > level, whereby some key translations are performed.  But then we'd
> > need to agree which translations are or aren't taken into
> > consideration.  In the above example, does Ctrl+A produce 01 decimal?
> > does Ctrl-[ produce ESC? what do the keys produce when the keyboard's
> > language is not English? etc.  And whether to perform this or not
> > should be controllable by Lisp.
> 
> This reaches far beyond the scope of just reporting modifier activation
> that is usually discarded by Emacs (and which is always reported by the
> X server).

So?  Emacs reaches far beyond many things.  We should ideally decide
what we want this feature to do, and then see how to implement it, not
the other way around.

Re: Physical keyboard events

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Mon, 04 Nov 2024 17:35:52 +0800
> 
> Cecilio Pardo <cpardo@imayhem.com> writes:
> 
> >> ??? Code producing such events should not relay modifier keysyms
> >> verbatim, but ought to detect the virtual modifiers to which they are
> >> mapped, and convert them into Emacs modifiers, namely, meta, alt, ctrl,
> >> hyper, super, and shift.  Otherwise, Lisp will find it impossible
> >> reliably to establish a correspondence between "physical key events" and
> >> modifiers.
> >
> > This is about keys, not modifiers. For the use case of binding
> > commands to keys, this remapping would be counterproductive. I can
> > provide a function to make that conversion if needed.
> 
> I must disagree.  When Emacs has enough information to decide which
> modifiers are produced by physical keys it receives, as it does here, it
> should not confuse Lisp programmers with a view of the keyboard state
> that runs contrary to their expectations, not to mention that the
> disparity between X keysyms and X modifiers is very great, and users who
> swap the positions of the Shift and Ctrl modifiers will not expect to
> receive raw keyboard events which disregard their keyboard
> configuration.

I don't think I agree with you.  I think I'm with Cecilio here.
Physical key events means that Emacs doesn't perform any conversions,
it leaves that to the Lisp program which receives such events.  E.g.,
when I press the Alt key, I expect to see an event of pressing the Alt
key, not a (non-existent) Meta.  And if I press the Right Alt key, I
expect to see AltGr, not Alt and not Meta.

> BTW, if the intention is to forward just modifier key events to Lisp,
> don't let's refer to them as "physical keyboard events", but in more
> specific terms.

Yes, I think the idea is to generate modifier key events and expose
them to Lisp.  What is more specific than "physical keyboard events"?

Re: Physical keyboard events

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> I don't think I agree with you.  I think I'm with Cecilio here.
> Physical key events means that Emacs doesn't perform any conversions,
> it leaves that to the Lisp program which receives such events.  E.g.,
> when I press the Alt key, I expect to see an event of pressing the Alt
> key, not a (non-existent) Meta.  And if I press the Right Alt key, I
> expect to see AltGr, not Alt and not Meta.

The issue is that X does not attach enough significance to keysyms
reliably to tell AltGr from Alt, or the like, with a keysym alone.  A
keysym is just that--a symbol printed on a key cap, and it is up to
users to bind these keys to modifier bits, all of which but Shift, Caps
Lock, and Ctrl are completely nondescript and for client programs such
as Emacs to interpret.

E.g., AltGr could be configured on the OS level to serve as a level 3
shift key, as it typically does, or as an entirely different modifier,
without affecting the keysym (XK_Alt_R _or_ XK_ISO_Level3_Shift) or even
the modifier bit (on my system, Mod5) generated.  Likewise, Caps Lock
could be configured to Control while continuing to be reported as
XK_Caps_Lock.

Emacs already tries to establish a sensible relationship between
modifier bits and Emacs modifiers, and clearly, the reasonable way
forward is to write a small quantity of code to deduce the modifier bits
produced by a keysym, and reuse the existing mechanism to report a
modifier that users will expect, instead of engineering a different
mechanism for the purposes of reporting modifier activation and
deactivation, or, as Cecilio's patch currently does, reporting keysyms
totally independent of the modifiers actually bound to their keys.

>> BTW, if the intention is to forward just modifier key events to Lisp,
>> don't let's refer to them as "physical keyboard events", but in more
>> specific terms.
>
> Yes, I think the idea is to generate modifier key events and expose
> them to Lisp.  What is more specific than "physical keyboard events"?

"Modifier activation and release events", perhaps?

Re: Physical keyboard events

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: cpardo@imayhem.com,  emacs-devel@gnu.org
> Date: Mon, 04 Nov 2024 22:37:44 +0800
> 
> Emacs already tries to establish a sensible relationship between
> modifier bits and Emacs modifiers, and clearly, the reasonable way
> forward is to write a small quantity of code to deduce the modifier bits
> produced by a keysym, and reuse the existing mechanism to report a
> modifier that users will expect, instead of engineering a different
> mechanism for the purposes of reporting modifier activation and
> deactivation, or, as Cecilio's patch currently does, reporting keysyms
> totally independent of the modifiers actually bound to their keys.

I can see a place for both.  It all depends on what the Lisp program
wants to do.  So I guess we should allow Lisp programs to receive one
or the other.

> >> BTW, if the intention is to forward just modifier key events to Lisp,
> >> don't let's refer to them as "physical keyboard events", but in more
> >> specific terms.
> >
> > Yes, I think the idea is to generate modifier key events and expose
> > them to Lisp.  What is more specific than "physical keyboard events"?
> 
> "Modifier activation and release events", perhaps?

That's a mouthful.  How about "low-level keyboard events"?

Re: Physical keyboard events

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Po Lu <luangruo@yahoo.com>
>> Cc: cpardo@imayhem.com,  emacs-devel@gnu.org
>> Date: Mon, 04 Nov 2024 22:37:44 +0800
>> 
>> Emacs already tries to establish a sensible relationship between
>> modifier bits and Emacs modifiers, and clearly, the reasonable way
>> forward is to write a small quantity of code to deduce the modifier bits
>> produced by a keysym, and reuse the existing mechanism to report a
>> modifier that users will expect, instead of engineering a different
>> mechanism for the purposes of reporting modifier activation and
>> deactivation, or, as Cecilio's patch currently does, reporting keysyms
>> totally independent of the modifiers actually bound to their keys.
>
> I can see a place for both.  It all depends on what the Lisp program
> wants to do.  So I guess we should allow Lisp programs to receive one
> or the other.

What _is_ the place for the second?  Binding commands to a modifier key
is possible whatever may be the name of the key to which they are bound
(alt or meta).  Besides, the patch as written doesn't implement either
behavior reliably, because it tests against a few specific keysym names,
which is not a reliable means of detecting modifier keys on X.

>> >> BTW, if the intention is to forward just modifier key events to Lisp,
>> >> don't let's refer to them as "physical keyboard events", but in more
>> >> specific terms.
>> >
>> > Yes, I think the idea is to generate modifier key events and expose
>> > them to Lisp.  What is more specific than "physical keyboard events"?
>> 
>> "Modifier activation and release events", perhaps?
>
> That's a mouthful.  How about "low-level keyboard events"?

This still misleadingly implies that keys beyond modifiers will be
reported.

Re: Physical keyboard events

[Cecilio Pardo]

On 05/11/2024 2:03, Po Lu wrote:
>>>>> BTW, if the intention is to forward just modifier key events to Lisp,
>>>>> don't let's refer to them as "physical keyboard events", but in more
>>>>> specific terms.
>>>>
>>>> Yes, I think the idea is to generate modifier key events and expose
>>>> them to Lisp.  What is more specific than "physical keyboard events"?
>>>
>>> "Modifier activation and release events", perhaps?
>>
>> That's a mouthful.  How about "low-level keyboard events"?
> 
> This still misleadingly implies that keys beyond modifiers will be
> reported.
The only use case right now is detecting taps in modifier keys, maybe 
long presses. If more use cases appear, the list of reported keys would 
be expanded.

Re: Physical keyboard events

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: cpardo@imayhem.com,  emacs-devel@gnu.org
> Date: Tue, 05 Nov 2024 09:03:00 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Po Lu <luangruo@yahoo.com>
> >> Cc: cpardo@imayhem.com,  emacs-devel@gnu.org
> >> Date: Mon, 04 Nov 2024 22:37:44 +0800
> >> 
> >> Emacs already tries to establish a sensible relationship between
> >> modifier bits and Emacs modifiers, and clearly, the reasonable way
> >> forward is to write a small quantity of code to deduce the modifier bits
> >> produced by a keysym, and reuse the existing mechanism to report a
> >> modifier that users will expect, instead of engineering a different
> >> mechanism for the purposes of reporting modifier activation and
> >> deactivation, or, as Cecilio's patch currently does, reporting keysyms
> >> totally independent of the modifiers actually bound to their keys.
> >
> > I can see a place for both.  It all depends on what the Lisp program
> > wants to do.  So I guess we should allow Lisp programs to receive one
> > or the other.
> 
> What _is_ the place for the second?

Which one is the second?

> Binding commands to a modifier key
> is possible whatever may be the name of the key to which they are bound
> (alt or meta).

But if there's no Meta key on the keyboard, emitting Meta will be
misleading, at least in some use cases.

> Besides, the patch as written doesn't implement either
> behavior reliably, because it tests against a few specific keysym names,
> which is not a reliable means of detecting modifier keys on X.

That's a separate issue.  We are discussing the principles here, and
principles don't depend on the particulars of some implementation.

> >> >> BTW, if the intention is to forward just modifier key events to Lisp,
> >> >> don't let's refer to them as "physical keyboard events", but in more
> >> >> specific terms.
> >> >
> >> > Yes, I think the idea is to generate modifier key events and expose
> >> > them to Lisp.  What is more specific than "physical keyboard events"?
> >> 
> >> "Modifier activation and release events", perhaps?
> >
> > That's a mouthful.  How about "low-level keyboard events"?
> 
> This still misleadingly implies that keys beyond modifiers will be
> reported.

If you were talking about modifier keys only, why do these events need
a separate name?  I suggested the above as the name for all raw
keyboard events, no matter which key is pressed/released.

Re: Physical keyboard events

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Mon, 04 Nov 2024 08:21:09 +0800
> 
> Cecilio Pardo <cpardo@imayhem.com> writes:
> 
> > +static void
> > +x_maybe_send_physical_key_event (struct x_display_info *dpyinfo, XEvent *event)
> > +{
> > +#ifdef HAVE_XKB
> 
> Thank you.  A number of comments: this is simply unacceptable, as Emacs
> must not depend on XKB for such a basic feature.

This is not a basic feature, from where I stand.  It's an enhancement.
My evidence is that Emacs has lived for 4 decades without it.

So please explain why would you reject an implementation of this which
requires XKB.

Re: Physical keyboard events

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> This is not a basic feature, from where I stand.  It's an enhancement.
> My evidence is that Emacs has lived for 4 decades without it.
>
> So please explain why would you reject an implementation of this which
> requires XKB.

It is a basic feature in that it can easily be implemented for systems
without XKB.

Re: Physical keyboard events

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: cpardo@imayhem.com,  emacs-devel@gnu.org
> Date: Mon, 04 Nov 2024 21:09:56 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > This is not a basic feature, from where I stand.  It's an enhancement.
> > My evidence is that Emacs has lived for 4 decades without it.
> >
> > So please explain why would you reject an implementation of this which
> > requires XKB.
> 
> It is a basic feature in that it can easily be implemented for systems
> without XKB.

That's a completely different motivation.  I agree that if a feature
can be easily implemented without extensions, and thus work in more
configurations, we should try implementing it without extensions.

Re: Physical keyboard events

[Cecilio Pardo]

On 04/11/2024 1:21, Po Lu wrote:

> x_filter_events is not the proper location for this call.  It is only
> invoked to filter an event through the active GTK or X input method
> context, and it is not invoked if Emacs is configured not to open input
> method contexts, or they are unavailable by happenstance.
> 
> This call is properly placed in handle_one_xevent, beneath the labels
> for KeyPress, KeyRelease, XI_KeyPress, XI_KeyRelease, and the GTK
> keyboard callbacks in gtkutil.c.  Pay attention to the different manners
> in which the key codes are converted into keysyms and the keysyms into
> modifiers, and imitate them closely or reuse them if possible.

In what configuration does the gtk callback get called? 
(xg_widget_key_press_event_cb in gtktutil.c).

Not with this one:

GNU Emacs 31.0.50 (build 33, x86_64-pc-linux-gnu, GTK+ Version 3.24.33, 
cairo version 1.16.0) of 2024-11-16

Re: Physical keyboard events

[Po Lu]

Cecilio Pardo <cpardo@imayhem.com> writes:

> On 04/11/2024 1:21, Po Lu wrote:
>
>> x_filter_events is not the proper location for this call.  It is only
>> invoked to filter an event through the active GTK or X input method
>> context, and it is not invoked if Emacs is configured not to open input
>> method contexts, or they are unavailable by happenstance.
>> This call is properly placed in handle_one_xevent, beneath the
>> labels
>> for KeyPress, KeyRelease, XI_KeyPress, XI_KeyRelease, and the GTK
>> keyboard callbacks in gtkutil.c.  Pay attention to the different manners
>> in which the key codes are converted into keysyms and the keysyms into
>> modifiers, and imitate them closely or reuse them if possible.
>
> In what configuration does the gtk callback get called?
> (xg_widget_key_press_event_cb in gtktutil.c).

Configurations where x-gtk-use-native-input is enabled.

> Not with this one:
>
> GNU Emacs 31.0.50 (build 33, x86_64-pc-linux-gnu, GTK+ Version
> 3.24.33, cairo version 1.16.0) of 2024-11-16

You'll need to enable that variable.

Re: Physical keyboard events

[Cecilio Pardo]

Hello,

I just opened bug#74423 with a new version of this patch.