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

[Stefan Monnier]

> 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?

The check on line 3262 seems odd.  If we trace it back it was introduced in
revision 1.489 in the following form:

    if (this_command_key_count == 0 || ! reread)

the log comment doesn't say much useful:

    (read_char): Call the input method if appropriate.
    Change logic for distinguishing rereads from new events;
    use local var `reread'.  Take events from
    Vunread_input_method_events and Vunread_post_input_method_events.

I'm not sure exactly what this was trying to avoid, but the test looks odd.
Maybe the "!reread" could make some sense, but the
"this_command_key_count==0" looks positively odd since it may end up
recording the first (and only the first) of a sequence of keys.

Maybe the problem is that `this-command-keys' has several potential uses and
they are incompatible: in one case one wants this-command-keys to list the
keys the user has typed (independently from whether or not some of those
keys were later read&unread&reread&reunread&rereread), whereas in the other
one wants the exact key-sequence which triggered this command, so we can
push it back on unread-command-events to force re-interpretation of
those keys.


        Stefan