GNU bug report logs - #22163
Feature request: Add support for key release event

Previous Next

To reply to this bug, email your comments to 22163 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Simon Friis Vindum <simonfv <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Feature request: Add support for key release event
Date: Sun, 13 Dec 2015 09:58:07 +0100

[Message part 1 (text/plain, inline)]

Dear Emacs developers

I apologize if this feature has been requested before. I was not able to
find any such requests.

The feature request:
It should be possible to bind functions to the _release_ of a key.
Additionally it would also be nice if it was possible to get the current
state of a key. I.e. is it pressed or not.

As far is I understand implementing this in the terminal is impossible—so
this feature would be for graphical environments only.

Motivation:
Here are a few ideas that I've wanted to implement as Emacs extensions.
They all turned out to be impossible due to the lack of this feature. To
implement them it would be necessary to be notified both when a key is
pressed and when a keys is released.

1/ The possibility of bindings commands to the long press of a key. For
instance I would bind a long press of `s` to `isearch-forward` and a long
press of `n` to `avy-goto-line-below`. The extension would calculate this
time difference between key press and release. And based on that decide
between short- and long-press behaviour.

2/ An extension that would make it possible to use a regular key as a
modifier key. For instance holding `j` with the right hand could activate
"wasd" directional keys for the left hand. Or holding `a` could activate
vim-like directional keys with "hjkl". The possibilities are many.

3/ Get press and hold behaviour independent of the OSs key repeat
behaviour. If I bind a function (e.g. one that scrolls the buffer a single
line) to a key binding then the behaviour will be like this: initial press
scrolls one line. Then there is a long delay. After that a single line is
scrolled with very short delays. It is controlled entirely by how key
repeat works in the OS. Getting rid of the initial long delay or
controlling the repeat interval is impossible.

In my initial search for this feature I came across a bunch of
StackOverflow questions that also asked for behaviour that would require
this functionality. Often the best answer was to use key-chords. But the
semantics of pressing two keys quickly after each other is quite different
from the press-and-hold semantics of a modifier.

Thank you for considering this.

Kind regards
Simon Friis Vindum

[Message part 2 (text/html, inline)]

Message #8 received at 22163 <at> debbugs.gnu.org (full text, mbox):

From: John Wiegley <jwiegley <at> gmail.com>
To: Simon Friis Vindum <simonfv <at> gmail.com>
Cc: 22163 <at> debbugs.gnu.org
Subject: Re: bug#22163: Feature request: Add support for key release event
Date: Mon, 14 Dec 2015 14:17:06 -0800

>>>>> Simon Friis Vindum <simonfv <at> gmail.com> writes:

> It should be possible to bind functions to the _release_ of a key.

Those who understand the fundamentals of event handling would know better, but
doing this right could be a rather invasive change. For example: Should
`read-event' return once a key is pressed down; or should it wait until the
key has been released, and then also give both the press-down and release
times? At the moment, it just notifies the user of the key?

Because once you have sensitive to "length of press", I imagine that's just
the start of additional information you'd want about events and how they
relate in time to each other...

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Message #11 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Simon Friis Vindum <simonfv <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: bug#22163: Feature request: Add support for key release event
Date: Tue, 15 Dec 2015 21:15:29 +0100

>>>>> John Wiegley <address <at> hidden> writes:

> Those who understand the fundamentals of event handling would know better, but
> doing this right could be a rather invasive change. For example: Should
> `read-event' return once a key is pressed down; or should it wait until the
> key has been released, and then also give both the press-down and release
> times? At the moment, it just notifies the user of the key?

I was thinking that one might define a new built-in function. It could
for instance
be called `define-key-release` and behave exactly like `define-key`
except that the
passed command would be triggered on key release instead of key press.

It seems to me like that would be backwards compatible and non-invasive.

> Because once you have sensitive to "length of press", I imagine that's just
> the start of additional information you'd want about events and how they
> relate in time to each other...

I think that if you can get the press and release of a key then you have access
to all information from the hardware. Everything else can be derived from that.

Kind regards
Simon Friis Vindum

Message #14 received at 22163 <at> debbugs.gnu.org (full text, mbox):

From: John Wiegley <jwiegley <at> gmail.com>
To: Simon Friis Vindum <simonfv <at> gmail.com>
Cc: 22163 <at> debbugs.gnu.org
Subject: Re: bug#22163: Feature request: Add support for key release event
Date: Tue, 15 Dec 2015 12:27:08 -0800

>>>>> Simon Friis Vindum <simonfv <at> gmail.com> writes:

> I was thinking that one might define a new built-in function. It could for
> instance be called `define-key-release` and behave exactly like `define-key`
> except that the passed command would be triggered on key release instead of
> key press.
> 
> It seems to me like that would be backwards compatible and non-invasive.

Sure, from the point of view of `define-key', it would be. What I meant is
that key-handling right now is done on the basis of received events, and that
"key pressed down" is not an event. We only have "key pressed".

I don't know how hard it would be to break up key events into multiple phases,
or how backwards compatible it would be to see a union of up/down phases as
equivalent to what we know now as a "key press" event.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.