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

[Chong Yidong]

Richard Stallman <address@hidden> writes:

> To really do the right thing, we would need to associate each unread
> key with a flag indicating whether it was previously added to
> this-command-keys.  That would be a very painful incompatibility, so I
> never wanted to do it, and I don't want to do it now.
>
>     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.
>
> I think that is true.
>
> I suggest that we add a new primitive that does precisely what
> `universal-argument-other-key' needs, and use it there.  That will be
> safe, in that the change can't break anything else.
>
> Does anyone disagree?

This would involve lugging around an extra set of variables, exactly
like `this_command_keys' and `this_command_key_count' except reread
events get updated there too.  Sounds ugly.

How about a variable that tells the command loop to re-insert reread
commands into `this-command-keys' until the next command?  The command
loop could automagically reset this at the start of the loop, in case
of a quit.  Then universal-argument could toggle this variable.