Regarding on-key-up event

Regarding on-key-up event

[Ag Ibragimov]

Can someone please point to articles of some sort, or discussions on why
Emacs does not support on-key-up event and only recognizes when a
key is pressed.

If I understand it right, there were certain important factors in the past, but
I'm curious, do we still have technical reasons today for why this
cannot, or should not be implemented?

Thank you!

Re: Regarding on-key-up event

[Eli Zaretskii]

> From: Ag Ibragimov <agzam.ibragimov@gmail.com>
> Date: Fri, 03 Feb 2023 11:31:46 -0600
> 
> 
> Can someone please point to articles of some sort, or discussions on why
> Emacs does not support on-key-up event and only recognizes when a
> key is pressed.

I don't think I understand the question.  Emacs produces a key event
when a key was pressed and then released.  So technically, we already
have an "on-key-up" event.

Re: Regarding on-key-up event

[Ag Ibragimov]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Ag Ibragimov <agzam.ibragimov@gmail.com>
>> Date: Fri, 03 Feb 2023 11:31:46 -0600
>> 
>> 
>> Can someone please point to articles of some sort, or discussions on why
>> Emacs does not support on-key-up event and only recognizes when a
>> key is pressed.
>
> I don't think I understand the question.  Emacs produces a key event
> when a key was pressed and then released.  So technically, we already
> have an "on-key-up" event.

But you can't register "on-release" event, right? That makes for example
difficult to implement UX similar to an app switcher in a desktop
manager - Alt+Tab. Where as long you keep holding Alt, pressing Tab
performs an action, but releasing Alt-key gets you out. Or even
something much simpler, like temporarily increasing the font-size while you
hold the key.

Re: Regarding on-key-up event

[Eli Zaretskii]

> From: Ag Ibragimov <agzam.ibragimov@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Fri, 03 Feb 2023 13:25:53 -0600
> 
> > I don't think I understand the question.  Emacs produces a key event
> > when a key was pressed and then released.  So technically, we already
> > have an "on-key-up" event.
> 
> But you can't register "on-release" event, right? That makes for example
> difficult to implement UX similar to an app switcher in a desktop
> manager - Alt+Tab. Where as long you keep holding Alt, pressing Tab
> performs an action, but releasing Alt-key gets you out.

Yes, you can "register" an on-release event, just not for modifier
keys like Shift or Alt.

> Or even something much simpler, like temporarily increasing the
> font-size while you hold the key.

While you hold a key, a typical keyboard auto-repeats, so I see no
problem here.

Re: Regarding on-key-up event

[Konstantin Kharlamov]

On Fri, 2023-02-03 at 21:39 +0200, Eli Zaretskii wrote:
> 
> While you hold a key, a typical keyboard auto-repeats, so I see no
> problem here.

I am not aware of any keyboard that repeats its events upon holding a key.
Repetition is usually implemented in a toolkit handling key events. A keyboard
typically sends a single "pressed" event, and then after you done holding a key
it sends a "released" event.

Here's a proof: I run `libinput debug-events --verbose`, then hold `j`:

    $ libinput debug-events --verbose
    […]
    -event6   KEYBOARD_KEY            +0.000s       *** (-1) pressed
    jjjjjjjjjjjjjjjjjj event6   KEYBOARD_KEY            +1.280s     *** (-1)
released
    […]

See, there are repeating `j` on the screen, but it's created by the Qt toolkit
of my Konsole terminal. Keyboard sent only 2 events: `pressed` and `released`.

Re: Regarding on-key-up event

[Konstantin Kharlamov]

On Sat, 2023-02-04 at 00:47 +0300, Konstantin Kharlamov wrote:
> On Fri, 2023-02-03 at 21:39 +0200, Eli Zaretskii wrote:
> > 
> > While you hold a key, a typical keyboard auto-repeats, so I see no
> > problem here.
> 
> I am not aware of any keyboard that repeats its events upon holding a key.
> Repetition is usually implemented in a toolkit handling key events. A keyboard
> typically sends a single "pressed" event, and then after you done holding a
> key
> it sends a "released" event.
> 
> Here's a proof: I run `libinput debug-events --verbose`, then hold `j`:
> 
>     $ libinput debug-events --verbose
>     […]
>     -event6   KEYBOARD_KEY            +0.000s       *** (-1) pressed
>     jjjjjjjjjjjjjjjjjj event6   KEYBOARD_KEY            +1.280s     *** (-1)
> released
>     […]
> 
> See, there are repeating `j` on the screen, but it's created by the Qt toolkit
> of my Konsole terminal. Keyboard sent only 2 events: `pressed` and `released`.

Oops, I forgot the tool hides key names by default for security reasons.
Should've passed a `--show-keycodes` option. The *** in the output supposed to
be a KEY_J.

Re: Regarding on-key-up event

[Po Lu]

This nice behavior may be guaranteed by a keyboard itself, but not by input methods, where it is actually impossible to match up an input method's committed key events with a corresponding key release event.

Of course, since the input method is not operating synchronously wrt the X connection, there is not even the guarantee that the key release arrives after the key press, since the latter are not filtered through it.  And for good reason; imagine that the input method commits a string, abcdef, and Emacs generates one key event for each character.

Which key release events should Emacs then deliver?

On February 4, 2023 5:47:14 AM GMT+08:00, Konstantin Kharlamov <hi-angel@yandex.ru> wrote:
>On Fri, 2023-02-03 at 21:39 +0200, Eli Zaretskii wrote:
>> 
>> While you hold a key, a typical keyboard auto-repeats, so I see no
>> problem here.
>
>I am not aware of any keyboard that repeats its events upon holding a key.
>Repetition is usually implemented in a toolkit handling key events. A keyboard
>typically sends a single "pressed" event, and then after you done holding a key
>it sends a "released" event.
>
>Here's a proof: I run `libinput debug-events --verbose`, then hold `j`:
>
>    $ libinput debug-events --verbose
>    […]
>    -event6   KEYBOARD_KEY            +0.000s       *** (-1) pressed
>    jjjjjjjjjjjjjjjjjj event6   KEYBOARD_KEY            +1.280s     *** (-1)
>released
>    […]
>
>See, there are repeating `j` on the screen, but it's created by the Qt toolkit
>of my Konsole terminal. Keyboard sent only 2 events: `pressed` and `released`.
>

Re: Regarding on-key-up event

[Ag Ibragimov]

Po Lu <Luangruo@yahoo.com> writes:

> This nice behavior may be guaranteed by a keyboard itself, but not by input methods, where it is actually impossible to match up an input method's committed key events with a corresponding key release event.
>
> Of course, since the input method is not operating synchronously wrt the X connection, there is not even the guarantee that the key release arrives after the key press, since the latter are not filtered through it.  And for good reason; imagine that the input method commits a string, abcdef, and Emacs generates one key event for each character.
>
> Which key release events should Emacs then deliver?

Aha! Thank you. All right, this completely makes sense. What about when Emacs doesn't connect to X Server? Cocoa, pgkt, etc. Or is it vital to keep the model for backward compatibility and consistency?

I can't be the first person asking this question: "why can't I bind a command to a key-release event?", right?

Re: Regarding on-key-up event

[Po Lu]

I think input methods pose this basic semantic problem on all systems.  They definitely do on GTK, in much the same way as they do on X.

On February 4, 2023 8:48:42 AM GMT+08:00, Ag Ibragimov <agzam.ibragimov@gmail.com> wrote:
>Po Lu <Luangruo@yahoo.com> writes:
>
>> This nice behavior may be guaranteed by a keyboard itself, but not by input methods, where it is actually impossible to match up an input method's committed key events with a corresponding key release event.
>>
>> Of course, since the input method is not operating synchronously wrt the X connection, there is not even the guarantee that the key release arrives after the key press, since the latter are not filtered through it.  And for good reason; imagine that the input method commits a string, abcdef, and Emacs generates one key event for each character.
>>
>> Which key release events should Emacs then deliver?
>
>Aha! Thank you. All right, this completely makes sense. What about when Emacs doesn't connect to X Server? Cocoa, pgkt, etc. Or is it vital to keep the model for backward compatibility and consistency?
>
>I can't be the first person asking this question: "why can't I bind a command to a key-release event?", right?
>
>

Re: Regarding on-key-up event

[Eli Zaretskii]

> From: Konstantin Kharlamov <hi-angel@yandex.ru>
> Cc: emacs-devel@gnu.org
> Date: Sat, 04 Feb 2023 00:47:14 +0300
> 
> On Fri, 2023-02-03 at 21:39 +0200, Eli Zaretskii wrote:
> > 
> > While you hold a key, a typical keyboard auto-repeats, so I see no
> > problem here.
> 
> I am not aware of any keyboard that repeats its events upon holding a key.
> Repetition is usually implemented in a toolkit handling key events.

This fine details is not relevant for the issue at hand: from Emacs's
POV, the exact place where the repetition happens is immaterial.

Re: Regarding on-key-up event

[Ag Ibragimov]

Eli Zaretskii <eliz@gnu.org> writes:

Sorry Eli, I accidentally replied without CC, so this one would show up
for you twice. My apologies.

>> From: Ag Ibragimov <agzam.ibragimov@gmail.com>
>> Cc: emacs-devel@gnu.org
>> Date: Fri, 03 Feb 2023 13:25:53 -0600
>> 
>> > I don't think I understand the question.  Emacs produces a key event
>> > when a key was pressed and then released.  So technically, we already
>> > have an "on-key-up" event.
>> 
>> But you can't register "on-release" event, right? That makes for example
>> difficult to implement UX similar to an app switcher in a desktop
>> manager - Alt+Tab. Where as long you keep holding Alt, pressing Tab
>> performs an action, but releasing Alt-key gets you out.
>
> Yes, you can "register" an on-release event, just not for modifier
> keys like Shift or Alt.
>

Wait, really? Are you saying that aside the modifier keys, it's possible to let's say
bind a command to a key e.g., (kbd "a"), so when a user presses the key,
it would to run one command, but when the key is released to run a
different command?

>> Or even something much simpler, like temporarily increasing the
>> font-size while you hold the key.
>
> While you hold a key, a typical keyboard auto-repeats, so I see no
> problem here.

Right, it would auto-repeat, registering a sequence of "key-pressed"
events, but can we detect when the key gets released?

Re: Regarding on-key-up event

[Po Lu]

Also, I forgot to say that key press repetition is implemented in the X server, not a toolkit.

On February 4, 2023 7:45:20 AM GMT+08:00, Ag Ibragimov <agzam.ibragimov@gmail.com> wrote:
>Eli Zaretskii <eliz@gnu.org> writes:
>
>Sorry Eli, I accidentally replied without CC, so this one would show up
>for you twice. My apologies.
>
>>> From: Ag Ibragimov <agzam.ibragimov@gmail.com>
>>> Cc: emacs-devel@gnu.org
>>> Date: Fri, 03 Feb 2023 13:25:53 -0600
>>> 
>>> > I don't think I understand the question.  Emacs produces a key event
>>> > when a key was pressed and then released.  So technically, we already
>>> > have an "on-key-up" event.
>>> 
>>> But you can't register "on-release" event, right? That makes for example
>>> difficult to implement UX similar to an app switcher in a desktop
>>> manager - Alt+Tab. Where as long you keep holding Alt, pressing Tab
>>> performs an action, but releasing Alt-key gets you out.
>>
>> Yes, you can "register" an on-release event, just not for modifier
>> keys like Shift or Alt.
>>
>
>Wait, really? Are you saying that aside the modifier keys, it's possible to let's say
>bind a command to a key e.g., (kbd "a"), so when a user presses the key,
>it would to run one command, but when the key is released to run a
>different command?
>
>>> Or even something much simpler, like temporarily increasing the
>>> font-size while you hold the key.
>>
>> While you hold a key, a typical keyboard auto-repeats, so I see no
>> problem here.
>
>Right, it would auto-repeat, registering a sequence of "key-pressed"
>events, but can we detect when the key gets released?
>

Re: Regarding on-key-up event

[Eli Zaretskii]

> From: Ag Ibragimov <agzam.ibragimov@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Fri, 03 Feb 2023 17:45:20 -0600
> 
> > Yes, you can "register" an on-release event, just not for modifier
> > keys like Shift or Alt.
> >
> 
> Wait, really? Are you saying that aside the modifier keys, it's possible to let's say
> bind a command to a key e.g., (kbd "a"), so when a user presses the key,
> it would to run one command, but when the key is released to run a
> different command?

No.  I already said that Emacs only receives a key when it is
released.  So we can have on-key-release events, but not on-key-press
events.  And pressing and release only a modifier key, such as Alt,
doesn't normally deliver any key event to Emacs.

> > While you hold a key, a typical keyboard auto-repeats, so I see no
> > problem here.
> 
> Right, it would auto-repeat, registering a sequence of "key-pressed"
> events, but can we detect when the key gets released?

The key-pressed events are actually key-release events, see above.

Re: Regarding on-key-up event

[chad]

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

In general, emacs is not interacting with the hardware at the level you're
talking about -- if it were, then emacs would have to (re-)implement things
like compose-keys that definitely belong at the system level. For emacs, as
I understand it, each window system or terminal maps the
specific interface to emacs' typical interface. By way of example, look at
pgtk_gtk_to_emacs_modifiers in pgtkterm.c, which is pretty simple because
the GTK interface is built on the GDK interface which grew more or less
directly out of the X11 interface, which also birthed emacs' internal
interface _for gui code_, but is not the same thing that emacs gets from
terminal interfaces. This last bit is why, for example, Control-I,
Control-[, and Control-Shift-Z are "tricky" for console emacs.

Another way to put it: despite the rumors/memes/stories, emacs isn't
actually an operating system (although it's not impossible to think of it
as a restricted virtual OS layered above the actual OS). It's probably
possible to change emacs to make it closer to the low-level interface for a
specific combination of UI and OS, and it would almost certainly break some
abstractions for other combinations.

I hope this helps,
~Chad

[-- Attachment #2: Type: text/html, Size: 1326 bytes --]