From: Jonathan Ganc <jonganc@gmail.com>
To: martin rudalics <rudalics@gmx.at>, 26104@debbugs.gnu.org
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 [thread overview]
Message-ID: <1d493e40-8d0d-a393-081f-55e32bef0857@gmail.com> (raw)
In-Reply-To: <58DF78AB.9010603@gmx.at>
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
>
next prev parent reply other threads:[~2017-04-04 0:59 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-15 3:25 bug#26104: 26.0.50; In Ubuntu, having mouse over other frame cause Alt key to produce a <switch-frame> event Jonathan Ganc
2017-03-17 7:19 ` martin rudalics
2017-03-18 1:04 ` Jonathan Ganc
2017-03-18 8:19 ` martin rudalics
2017-04-01 9:53 ` martin rudalics
2017-04-04 0:59 ` Jonathan Ganc [this message]
2017-04-05 6:58 ` martin rudalics
2017-04-07 3:56 ` Jonathan Ganc
2017-04-07 5:56 ` martin rudalics
2017-04-07 15:27 ` Jonathan Ganc
2017-04-08 8:59 ` martin rudalics
2017-04-08 22:42 ` Jonathan Ganc
2017-04-09 6:37 ` martin rudalics
2017-04-15 9:41 ` Jonathan Ganc
2017-04-15 14:50 ` martin rudalics
2017-04-15 15:11 ` Eli Zaretskii
2017-04-15 19:39 ` martin rudalics
2017-04-15 20:23 ` Jonathan Ganc
2017-04-16 7:15 ` martin rudalics
2017-04-15 20:33 ` Jonathan Ganc
2022-04-21 15:15 ` Lars Ingebrigtsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1d493e40-8d0d-a393-081f-55e32bef0857@gmail.com \
--to=jonganc@gmail.com \
--cc=26104@debbugs.gnu.org \
--cc=rudalics@gmx.at \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.