Re: Behavior of `this-command-keys'

[Kim F. Storm]

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