read-event in `repeat' command

[Drew Adams]

I use popup frames a lot.  By default, that is how a buffer gets displayed in my
setup.

I'm also on MS Windows, which has the property that a newly created frame is
always selected (obtains the focus). This means that displaying a buffer is
different, depending on whether its frame already exists. If it does, then the
focus (typically) does not change to the buffer's frame.  If it does not, then
the focus moves there. I work around this focus-grabbing annoyance sometimes by
using `select-frame-set-input-focus' at appropriate places. (Ugh!)

Anyway, the problem I'm writing about is with the `repeat' command. Presumably,
it tries to be sensitive to actual user events, such as typing a character, but
ignore other, non-user events.  Currently, this does not work for me in some
cases - an automatic `switch-frame' event is causing it to stop repeating.

I have a command that displays a buffer in its own frame (the same frame or
another, possibly new, frame). I make it repeatable using `repeat', and I bind
it to a key, say `f'.  That works fine in general: hitting `f f f...' continues
to display buffers - in new frames or existing frames.  No problem.

But in some cases my command also pops up an additional buffer, in another
frame.  In those cases the repetition breaks as soon as that second buffer is
displayed. Hitting `f' at that point just inserts an `f' character (in that
buffer if it was selected, else in the first buffer displayed by `f').  It does
not matter whether the second buffer and its frame already exist or not.

I mentioned the frame focus above, but that is apparently not the problem. It
does not matter whether the `f' command opens the first buffer in a new frame or
an existing frame, and likewise for the second buffer. And it does not matter
whether the second buffer is selected (and its frame focused) or not.

It is only when hitting `f' opens also a second buffer that a subsequent `f'
just inserts.

However, if I make a copy of the definition of command `repeat' and change only
its `read-event' to `read-char-exclusive', then the problem goes away.  So some
event being read is being tested and found to be different from the `f' last
input event, thus ending the repetition.

I'm guessing that this is what happens: The `read-event' reads the `f' and
repeats the command, which displays the first and second buffers. I would think
there would be a `switch-frame' event associated with each buffer display, but
maybe not. In any case, if there is a `switch-frame' for the first buffer
display it is ignored, but the `switch-frame' for the second buffer display
causes repetition to stop.

It is difficult to use the debugger with `repeat', so I copied the code and
inserted a call to `message' after the `read-event'.  It shows clearly that
display of the second buffer causes the event read to be a `switch-frame'.

Now I imagine that we intentionally use `read-event' here in order to let
`repeat' work with other user events besides just char input (e.g. mouse
clicks), so that changing `read-event' to `read-char-exclusive' would not be the
correct fix.

Can someone please help with this question? How can we get the fail-safe
behavior of `read-char-exclusive' but without also eliminating repeated non-char
user events such as mouse clicks?

Or is `read-char-exclusive' in fact the right fix?  I'm not clear about this.
Suggestions welcome. Thx.