Monitoring KeyRelease

Monitoring KeyRelease

[Alexander Klimov]

Instead of normal modifiers (C-, M-, ...), it would be nice to use the 
usual keys (such as `f' or `j') as modifiers and thus do the most 
common operations without leaving the home row (e.g., instead of 
C-f/C-b do, say, j-f/j-b, that is hold j and press either f or b).

key-chord.el shows that it is possible to use the time to decide that 
several keys represent a chord. This approach is inconvenient since it 
requires the keys to be never used in usual words and does not allow 
to hold the "modifier" and repeat only the other key.

The proper way seems to require handling KeyPress/KeyRelase, but it 
seems Emacs currently ignores KeyRelease (xterm.c:6680).

Do I understand correctly that in the current Emacs version, while 
processing a keypress, it is impossible to get information about which 
other keys are pressed? What you think is the easiest way to fix this?

-- 
Regards,
ASK

Re: Monitoring KeyRelease

[Stefan Monnier]

> The proper way seems to require handling KeyPress/KeyRelase, but it 
> seems Emacs currently ignores KeyRelease (xterm.c:6680).

That could be changed, of course.


        Stefan

Re: Monitoring KeyRelease

[Alexander Klimov]

On Thu, 5 Jul 2012, Stefan Monnier wrote:
> > The proper way seems to require handling KeyPress/KeyRelase, but it 
> > seems Emacs currently ignores KeyRelease (xterm.c:6680).
> 
> That could be changed, of course.

Looks like it is more complicated than it seems.

I added logging of KeyPress/KeyRelease: event.xkey.keycode, `[' or ']'
(means press or release), event.xkey.time-last_user_time, and keysym if
ASCII. Turns out I commonly press the next key before releasing the
previous one, for example, `test' looks like

   28 [ 1719 't'
   26 [ 88 'e'
   28 ] 64
   39 [ 24 's'
   26 ] 80
   28 [ 40 't'
   39 ] 40
   28 ] 88

`just a test' looks like

   44 [ 652 'j'
   44 ] 128
   30 [ 128 'u'
   39 [ 80 's'
   30 ] 24
   28 [ 88 't'
   39 ] 72
   65 [ 40 ' '
   28 ] 96
   65 ] 24
   38 [ 48 'a'
   65 [ 136 ' '
   38 ] 48
   65 ] 128
   28 [ 56 't'
   26 [ 88 'e'
   28 ] 24
   39 [ 40 's'
   26 ] 56
   28 [ 48 't'
   39 ] 64
   28 ] 96

while using `f' as a modifier and moving cursor with `j', `l', or `k'
looks like

   41 [ 1136 'f'
   44 [ 328 'j'
   44 ] 96
   44 [ 64 'j'
   44 ] 80
   44 [ 72 'j'
   44 ] 72
   44 [ 72 'j'
   44 ] 120
   46 [ 1257 'l'
   46 ] 55
   46 [ 80 'l'
   46 ] 88
   41 ] 624

That is if I use a key as a modifier it actually takes longer to press 
the next key than when I am typing a word and hold the previous key 
unintentionally.

I guess, we should collect all the event information during KeyPress, 
but do not store the event into the kbd_buffer until we get the 
corresponding KeyRelease. While processing the KeyRelease we should 
add to the corresponding KeyPress event the information about all 
"extended modifiers" which are currently pressed. If we used an 
extended modifier, than we should remember this fact and skip adding 
it to the kbd_buffer while processing its KeyRelease event. A key X 
can be considered as a modifier for key Y, only if X was pressed 
before Y and X is still pressed while Y is released.

overlap:

  ----- time ----->
  t [         ]
  e      [        ]

modifier:

  ----- time ----->
  f [             ]
  j      [     ]

For example,

   28 [ 1719 't'    remember `t'
   26 [ 88 'e'      remember `e'
   28 ] 64          store `t' to kbd_buffer, not `e-t' since `e' was
                    pressed after `t'
   39 [ 24 's'      remember `s'
   26 ] 80          store `e'
   28 [ 40 't'      remember `t'
   39 ] 40          store `s'
   28 ] 88          store `t'

and

   41 [ 1136 'f'    remember `f'
   44 [ 328 'j'     remember `j'
   44 ] 96          store `f-j' (`f' was pressed before `j') and mark
                    `f' as been used as a modifier
   44 [ 64 'j'      remember `j'
   44 ] 80          store `f-j'
              [...]
   41 ] 624         skip `f' since it was used as modifier

Am I missing something and what you think is the best way to 
actually implement this scheme?

-- 
Regards,
ASK

Re: Monitoring KeyRelease

[Andreas Schwab]

Alexander Klimov <alserkli@inbox.ru> writes:

> I guess, we should collect all the event information during KeyPress, 
> but do not store the event into the kbd_buffer until we get the 
> corresponding KeyRelease.

That would mean that you wouldn't see the key until you release the key
or auto repeat kicks in. That would be quite irritating.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Monitoring KeyRelease

[chad]

Have you tried this on a terminal?  My understanding is that it just won't work on most terminals, but it's been a long time (~15 years) since I actually looked.  

At the time, it seemed like letter-based modifiers were routinely unclean. There were some combinations that were workable, but they depended on the keyboard layout (basically, you take advantage of the qwerty pretzel-combos).  The spacebar is a pretty solid potential modifier, because almost everyone hits it with their thumb, but there's some annoying IP in this area.

Hope that helps,
*Chad



On Jul 6, 2012, at 11:38 AM, Alexander Klimov wrote:

> Looks like it is more complicated than it seems.

Re: Monitoring KeyRelease

[Alexander Klimov]

On Fri, 6 Jul 2012, Andreas Schwab wrote:
> That would mean that you wouldn't see the key until you release the key
> or auto repeat kicks in. That would be quite irritating.

I missed the auto-repeat since I never use it, but you are right, it 
must also be considered.

I guess your both points are actually related: the only case where a 
user presses a key and expects a result before releasing the key, is 
when he is waiting for auto-repeat. Probably, it can be solved by an 
option: if allow-extended-modifiers is set, then auto-repeat is 
disabled (Emacs ignores KeyPress for a key that is already pressed).

-- 
Regards,
ASK

Re: Monitoring KeyRelease

[Alexander Klimov]

On Fri, 6 Jul 2012, chad wrote:
> Have you tried this on a terminal?  My understanding is that it just 
> won't work on most terminals, but it's been a long time (~15 years) 
> since I actually looked.

I have not tried, but you are right -- it will not work on terminal, 
at least not on remote host, since such terminals do not provide an 
analog of KeyRelease. 

OTOH, there are many features in Emacs that do not work in every UI 
(say, in-line images), but it does not make these features less useful 
in situations where they do work.

> At the time, it seemed like letter-based modifiers were routinely 
> unclean. There were some combinations that were workable, but they 
> depended on the keyboard layout (basically, you take advantage of 
> the qwerty pretzel-combos).  The spacebar is a pretty solid 
> potential modifier, because almost everyone hits it with their 
> thumb, but there's some annoying IP in this area.

Probably the whole idea that modifier must be a separate key is an 
atavism of the mechanical design: on a computer keyboard any key can 
be potentially used as a modifier. The advantage is a reduction of RSI 
since pressing a key in the home row is easier than pressing the 
proper modifier.

-- 
Regards,
ASK