Re: Strange behavior of C-u in the presence of sit-for in p-c-h

[Chong Yidong]

Chong Yidong <address@hidden> writes:

> Here is an easy way to reproduce the underlying bug:
>
> (defun foo ()
>   (interactive)
>   (universal-argument)
>   (push ?a unread-command-events))
>
> M-x foo RET
>
> The expected result is aaaa, but in fact nothing is printed.

The problem here is that C-u works through the command
`universal-argument-other-key', which sets prefix-arg and then adds
(this-command-keys) to unread-command-events so that it is executed
with that prefix argument.

This normally works ok.  However, suppose the call to
read_key_sequence in the command loop takes its input from
unread-command-events.  (This happens if the input came during a
sit-for in post-command-hook, as in Stefan's original example, or
directly as in the example above.)  This kind of "reread input" is
explicitly *not* added to this_command_keys.  The rationale for this
is not clear to me, but there may be a good reason since the code
explicitly checks for this; see keyboard.c:789.  Then
`universal-argument-other-key' can't see that input.

OTOH, I don't see a safe way of fixing this.  Any suggestions?