> IIUC we don't "send" that command anywhere. We rather put it in the
> event queue to tell ourselves that we are now in a safe and
> "historically accurate" place to run Lisp, select that frame's selected
> window and run some associated hooks. Maybe someone can tell us the
> real purpose.
Maybe we should start with finding out how that switch-frame event gets
generated. keyboard.c has this
/* Try generating a mouse motion event. */
else if (!NILP (do_mouse_tracking) && some_mouse_moved ())
{
...
if (! EQ (frame, internal_last_event_frame)
&& !EQ (frame, selected_frame))
obj = make_lispy_switch_frame (frame);
internal_last_event_frame = frame;
and from your description "and the mouse is positioned over the other
frame" your problem is likely triggered there.
If you set the variable ‘track-mouse’ to nil do you still see the
problem? Since this probably won't help when you are within the body of
a ‘track-mouse’ form, you would have to trace invocations of the latter
too.
If the event is triggered this way we seem to have a contradiction
because the doc-string of ‘handle-switch-frame’ says
A switch-frame event tells Emacs that the window manager has requested
that the user’s events be directed to the frame mentioned in the event.
but in the above scenario the window manager is apparently not involved.
In either case it will be debatable whether we should allow the mouse to
do anything "significant" in between C-y and M-y. IIUC, the philosophy
for M-y to succeed is that your fingers didn't move away from the
keyboard after the previous C-y. Otherwise, we'd have to decide whether
to allow mouse scrolling or window autoselection in between C-y and M-y
as well. Here, with focus follows mouse, leaving a frame with the mouse
without entering another one is already sufficient to make M-y fail.
And if your window manager has a strict focus policy, the M-y won't even
make it to your Emacs frame ;-)
martin