[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: Jonathan Ganc
Subject: bug#26104: 26.0.50; In Ubuntu, having mouse over other frame cause Alt key to produce a <switch-frame> event
Date: Mon, 3 Apr 2017 20:59:44 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0

Hi Martin,

Thanks for your comment. I was a bit slow to respond because I was bit intimidated to start looking at the c code! Sorry.

It should be noted that I don't know that actually moving the mouse plays a role here. As long as the mouse cursor is over the other frame, the issue happens, even if I don't actually move it. Setting track-mouse doesn't make a difference.

I think trying to figure out where the switch-frame actually gets triggered is a good idea. It looks like I'm going to have to try doing some serious spelunking (at least for me)! As I think you suggest, I want to try to figure out what is getting sent by xwindows vs what is being generated by emacs itself.

On 04/01/2017 05:53 AM, martin rudalics wrote:
> 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]