[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:

   (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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]