[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Behavior of `this-command-keys'
From: |
Kim F. Storm |
Subject: |
Re: Behavior of `this-command-keys' |
Date: |
Tue, 12 Sep 2006 00:13:13 +0200 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) |
Jay Belanger <address@hidden> writes:
> The behavior of `this-command-keys' doesn't seem to match its
> documentation; perhaps I'm misunderstanding something.
No, you have found a rather nasty bug.
> Consider something like:
> (defun test ()
> (interactive)
> (sit-for 1)
> (setq result (this-command-keys)))
> (global-set-key "a" 'test)
> To me, it sounds like as if `result' should equal "a" (the key which
> calls the function) if "ab" were pressed, whether or not the `sit-for'
> had run its course. However, `result' equals "a" or "ab" depending on
> how close together the "a" and "b" are pressed.
Since sit-for calls read-event internally, the result depends on whether
you type the b while sit-for is inside read-event or not.
That is obviously a bug.
As far as I can see, we need a non-destructive version of read-event
(wait-for-input SECONDS)
But we almost have that:
(while-no-input
(sleep-for SECONDS))
The only problem is that a selection event will interrupt while-no-input.
This is very annoying - also for other purposes than this.
What can we do?
--
Kim F. Storm <address@hidden> http://www.cua.dk