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

[Richard Stallman]

    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.

I designed that test to do the right thing in the cases that were
encountered, and both conditions proved to be necessary.

!reread is the usual case of reading a new character.

this_command_key_count==0 is the case you get when a command reads
input with read-event and then unreads it.  This usually IS the first
event of a key sequence; it is supposed to be.

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?  Would someone like to do this?