unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Alexander Klimov <alserkli@inbox.ru>
To: emacs-devel@gnu.org
Cc: Stefan Monnier <monnier@iro.umontreal.ca>
Subject: Re: Monitoring KeyRelease
Date: Fri, 6 Jul 2012 21:38:47 +0300	[thread overview]
Message-ID: <TheMailAgent.28e0b4f0@3e482444> (raw)
In-Reply-To: <jwvzk7ej78u.fsf-monnier+emacs@gnu.org>

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



  reply	other threads:[~2012-07-06 18:38 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-05 17:25 Monitoring KeyRelease Alexander Klimov
2012-07-05 20:14 ` Stefan Monnier
2012-07-06 18:38   ` Alexander Klimov [this message]
2012-07-06 18:47     ` Andreas Schwab
2012-07-06 21:20       ` Alexander Klimov
2012-07-06 19:00     ` chad
2012-07-06 22:05       ` Alexander Klimov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=TheMailAgent.28e0b4f0@3e482444 \
    --to=alserkli@inbox.ru \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).