[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#26104: 26.0.50; In Ubuntu, having mouse over other frame cause Alt k

From: martin rudalics
Subject: bug#26104: 26.0.50; In Ubuntu, having mouse over other frame cause Alt key to produce a <switch-frame> event
Date: Sat, 01 Apr 2017 11:53:47 +0200

> 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

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 ;-)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]