GNU bug report logs - #26104
26.0.50; In Ubuntu, having mouse over other frame cause Alt key to produce a <switch-frame> event

Previous Next

Full log

Message #20 received at 26104 <at> debbugs.gnu.org (full text, mbox):

From: Jonathan Ganc <jonganc <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>, 26104 <at> debbugs.gnu.org
Subject: Re: 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

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.