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

Package: emacs;

Reported by: Jonathan Ganc <jonganc <at> gmail.com>

Date: Wed, 15 Mar 2017 03:26:02 UTC

Severity: normal

Found in version 26.0.50

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 26104 in the body.
You can then email your comments to 26104 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#26104; Package emacs. (Wed, 15 Mar 2017 03:26:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Ganc <jonganc <at> gmail.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Wed, 15 Mar 2017 03:26:02 GMT) Full text and rfc822 format available.

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

From: Jonathan Ganc <jonganc <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 26.0.50; In Ubuntu, having mouse over other frame cause Alt key to
 produce a <switch-frame> event
Date: Tue, 14 Mar 2017 23:25:24 -0400

In Ubuntu, if I have two frames open and the mouse is positioned over 
the other frame (i.e. not over the active one), pressing the Alt key 
produces a <switch-frame> event.

While this event does nothing in itself, it disrupts things like 
yank-pop, which no longer works if it is bound to M-y as usual (because 
instead of the command sequence yank -> yank-pop, we now have yank -> 
handle-switch-frame -> yank-pop, which gives an error "user-error: 
Previous command was not a yank").

To be honest, I don't know enough about X-Windows to know if this is 
emacs' fault or x-windows fault. But it's very annoying.

[Tried on Emacs versions 24.5, 25.1, and the 26.0 and Ubuntu 16.10.]


In GNU Emacs 26.0.50 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.20.9)
 of 2017-03-13 built on lgw01-17
Windowing system distributor 'The X.Org Foundation', version 11.0.11804000
System Description:    Ubuntu 16.10

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Making completion list...

Configured using:
 'configure --build=x86_64-linux-gnu --prefix=/usr
 '--includedir=${prefix}/include' '--mandir=${prefix}/share/man'
 '--infodir=${prefix}/share/info' --sysconfdir=/etc --localstatedir=/var
 --disable-silent-rules '--libdir=${prefix}/lib/x86_64-linux-gnu'
 '--libexecdir=${prefix}/lib/x86_64-linux-gnu' --disable-maintainer-mode
 --disable-dependency-tracking --prefix=/usr --sharedstatedir=/var/lib
 --program-suffix=-snapshot --with-modules=yes --with-x=yes
 --with-x-toolkit=gtk3 --with-xwidgets=yes 'CFLAGS=-g -O2
 -fdebug-prefix-map=/build/emacs-snapshot-5_17hP/emacs-snapshot-93215-94b59f7-emacs=. -fstack-protector-strong
 -Wformat -Werror=format-security' 'CPPFLAGS=-Wdate-time
 -D_FORTIFY_SOURCE=2' 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro''

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GCONF GSETTINGS
NOTIFY LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 MODULES XWIDGETS LIBSYSTEMD

Important settings:
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message puny seq byte-opt subr-x gv
bytecomp byte-compile cl-extra help-mode cconv cl-loaddefs pcase cl-lib
dired dired-loaddefs format-spec rfc822 mml easymenu mml-sec
password-cache epa derived epg epg-config gnus-util rmail rmail-loaddefs
mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils
mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr
mail-utils time-date mule-util tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow isearch timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite charscript case-table epa-hook jka-cmpr-hook help
simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs button
faces cus-face macroexp files text-properties overlay sha1 md5 base64
format env code-pages mule custom widget hashtable-print-readable
backquote dbusbind inotify dynamic-setting system-font-setting
font-render-setting xwidget-internal move-toolbar gtk x-toolkit x
multi-tty make-network-process emacs)

Memory information:
((conses 16 96862 6611)
 (symbols 48 20194 1)
 (miscs 40 47 82)
 (strings 32 17628 4506)
 (string-bytes 1 566213)
 (vectors 16 14655)
 (vector-slots 8 483106 4490)
 (floats 8 48 68)
 (intervals 56 290 0)
 (buffers 976 12))





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#26104; Package emacs. (Fri, 17 Mar 2017 07:21:02 GMT) Full text and rfc822 format available.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Jonathan Ganc <jonganc <at> gmail.com>, 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: Fri, 17 Mar 2017 08:19:56 +0100
> In Ubuntu, if I have two frames open and the mouse is positioned over the other frame (i.e. not over the active one), pressing the Alt key produces a <switch-frame> event.
>
> While this event does nothing in itself, it disrupts things like yank-pop, which no longer works if it is bound to M-y as usual (because instead of the command sequence yank -> yank-pop, we now have yank -> handle-switch-frame -> yank-pop, which gives an error "user-error: Previous command was not a yank").
>
> To be honest, I don't know enough about X-Windows to know if this is emacs' fault or x-windows fault. But it's very annoying.
>
> [Tried on Emacs versions 24.5, 25.1, and the 26.0 and Ubuntu 16.10.]

Could you try in simple.el to replace

  (if (not (eq last-command 'yank))
      (user-error "Previous command was not a yank"))

with

  (if (not (memq last-command '(yank handle-switch-frame)))
      (user-error "Previous command was not a yank"))

Thanks, martin




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#26104; Package emacs. (Sat, 18 Mar 2017 01:06:02 GMT) Full text and rfc822 format available.

Message #11 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: Fri, 17 Mar 2017 21:04:57 -0400
Hi.

That does fix the problem for yank-pop, but I don't think it's a good 
fix. For example, it let's someone use yank-pop without having used yank 
if they use handle-switch-frame before. Also, the same issue happens 
with other commands like dabbrev-expand, which relies on checking what 
the previous command was.

What is the purpose of executing `handle-switch-frame` at all? Maybe 
there's some way of excluding it from last-command. But again, I don't 
really understand x-windows well or why that command is being sent.

Jonathan


On 03/17/2017 03:19 AM, martin rudalics wrote:
> > In Ubuntu, if I have two frames open and the mouse is positioned 
> over the other frame (i.e. not over the active one), pressing the Alt 
> key produces a <switch-frame> event.
> >
> > While this event does nothing in itself, it disrupts things like 
> yank-pop, which no longer works if it is bound to M-y as usual 
> (because instead of the command sequence yank -> yank-pop, we now have 
> yank -> handle-switch-frame -> yank-pop, which gives an error 
> "user-error: Previous command was not a yank").
> >
> > To be honest, I don't know enough about X-Windows to know if this is 
> emacs' fault or x-windows fault. But it's very annoying.
> >
> > [Tried on Emacs versions 24.5, 25.1, and the 26.0 and Ubuntu 16.10.]
>
> Could you try in simple.el to replace
>
>   (if (not (eq last-command 'yank))
>       (user-error "Previous command was not a yank"))
>
> with
>
>   (if (not (memq last-command '(yank handle-switch-frame)))
>       (user-error "Previous command was not a yank"))
>
> Thanks, martin





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#26104; Package emacs. (Sat, 18 Mar 2017 08:20:02 GMT) Full text and rfc822 format available.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Jonathan Ganc <jonganc <at> gmail.com>, 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: Sat, 18 Mar 2017 09:19:04 +0100
> That does fix the problem for yank-pop, but I don't think it's a good
> fix. For example, it let's someone use yank-pop without having used
> yank if they use handle-switch-frame before. Also, the same issue
> happens with other commands like dabbrev-expand, which relies on
> checking what the previous command was.

It wasn't meant to fix anything.  I just wanted to know whether
bypassing this error would allow ‘yank-pop’ to proceed without further
problems.

> What is the purpose of executing `handle-switch-frame` at all? Maybe
> there's some way of excluding it from last-command. But again, I don't
> really understand x-windows well or why that command is being sent.

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.

martin





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#26104; Package emacs. (Sat, 01 Apr 2017 09:54:02 GMT) Full text and rfc822 format available.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Jonathan Ganc <jonganc <at> gmail.com>, 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: 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
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





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#26104; Package emacs. (Tue, 04 Apr 2017 01:00:04 GMT) Full text and rfc822 format available.

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
>





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#26104; Package emacs. (Wed, 05 Apr 2017 06:59:02 GMT) Full text and rfc822 format available.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Jonathan Ganc <jonganc <at> gmail.com>, 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: Wed, 05 Apr 2017 08:58:23 +0200
> 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.

‘yank-pop’ by itself does not query the mouse position so "pressing the
Alt key produces a <switch-frame> event" as you said earlier does not
describe what really happens.  Someone else must have changed
`last-command' to `switch-frame' and it would be essential to find out
who.  And, as a furthe clue, the event must have come from a mouse move
since according to "the mouse is positioned over the other frame" this
is the only thing you do in between ‘yank’ and ‘yank-pop’ and if you do
not move the mouse in between them the M-y succeeds.  Or am I missing
something?

Now a frame switch triggered by mouse movement can only occur on
behalf of two underlying processes:

(1) The "window system" when tracking the mouse pointer tells us that it
    has crossed an edge from (focus-out-hook, mouse-leave-buffer-hook)
    or to (focus-in-hook) one of our window system windows.

(2) Emacs itself is tracking the mouse via `track-mouse' or something
    the like.

As for (1) I mentioned these hooks because they would allow you to put a
function on them in order to track what triggers your `switch-frame'
event.  As for (2) you would have to find all users/callers of
`track-mouse', inject some extra code in it to track its use and
recompile/reevaluate the users.

Simple put some code there that beeps like

(add-hook 'focus-in-hook 'ding)

and look what's happening.

All this would enable you to find out who generates a switch-frame event
although your mouse movements were apparently innocuous enough to never
motivate such an insertion.  If and when you find out the reason of that
insertion, we might be able to try to (optionally) prevent it.

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

If the above approach is inusfficient we indeed might have to add some
extra code to make_lispy_switch_frame in order to find out what happens.
In that case you have to be able to build Emacs on your machine.

martin





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#26104; Package emacs. (Fri, 07 Apr 2017 03:57:01 GMT) Full text and rfc822 format available.

Message #26 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: Thu, 6 Apr 2017 23:56:11 -0400
On 04/05/2017 02:58 AM, martin rudalics wrote:
>
> ‘yank-pop’ by itself does not query the mouse position so "pressing the
> Alt key produces a <switch-frame> event" as you said earlier does not
> describe what really happens.  Someone else must have changed
> `last-command' to `switch-frame' and it would be essential to find out
> who.  And, as a furthe clue, the event must have come from a mouse move
> since according to "the mouse is positioned over the other frame" this
> is the only thing you do in between ‘yank’ and ‘yank-pop’ and if you do
> not move the mouse in between them the M-y succeeds.  Or am I missing
> something?

switch-frame is produced when the Alt key is pressed (as soon as it is 
pressed, i.e. before the 'Y' is pressed). i can verify this by running 
'read-event`, which triggers and produces switch-frame as soon as Alt is 
pressed. Conversely, the event is still generated even if I disable both 
my mouse and trackpad, the only things which can produce mouse motion.

>
> If the above approach is inusfficient we indeed might have to add some
> extra code to make_lispy_switch_frame in order to find out what happens.
> In that case you have to be able to build Emacs on your machine.
>

I'm not averse to rebuilding emacs (I built the current version I'm 
using), if it could help.

I was trying to explore emacs input. One thing I've realized is that xev 
(i.e. if I monitor emacs using 'xev -id ...') does not see most keys 
(e.g. alphanumeric keys, Ctrl, shift) sent to emacs but it does see when 
Alt (or the Windows key) is pressed. So some keys are "special". I wish 
I knew about how emacs set this up.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#26104; Package emacs. (Fri, 07 Apr 2017 05:57:02 GMT) Full text and rfc822 format available.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Jonathan Ganc <jonganc <at> gmail.com>, 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: Fri, 07 Apr 2017 07:56:12 +0200
> switch-frame is produced when the Alt key is pressed (as soon as it is
> pressed, i.e. before the 'Y' is pressed). i can verify this by running
> 'read-event`, which triggers and produces switch-frame as soon as Alt
> is pressed. Conversely, the event is still generated even if I disable
> both my mouse and trackpad, the only things which can produce mouse
> motion.

Sorry for the silly question: Earlier you said that

  In Ubuntu, if I have two frames open and the mouse is positioned over
  the other frame (i.e. not over the active one), pressing the Alt key
  produces a <switch-frame> event.

and now you say that "the event is still generated even if I disable
both my mouse and trackpad".  How can you position the mouse when you
disable it?

martin




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#26104; Package emacs. (Fri, 07 Apr 2017 15:28:01 GMT) Full text and rfc822 format available.

Message #32 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: Fri, 7 Apr 2017 11:27:38 -0400
> and now you say that "the event is still generated even if I disable
> both my mouse and trackpad".  How can you position the mouse when you
> disable it?
>
> martin

Magical incantations! ;-) I positioned it and then used `xinput disable 
ID` for both my mouse and trackpad.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#26104; Package emacs. (Sat, 08 Apr 2017 09:01:02 GMT) Full text and rfc822 format available.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Jonathan Ganc <jonganc <at> gmail.com>, 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: Sat, 08 Apr 2017 10:59:58 +0200
[Message part 1 (text/plain, inline)]
> Magical incantations! ;-) I positioned it and then used `xinput
> disable ID` for both my mouse and trackpad.

And what would make you that sure that the `handle-switch-frame' event
was not inserted before you disabled xinput?

Anyway, as a first attempt try to apply the attached patch to keyboard.c
and tell me what the value of the variable `lispy-switch-frame-source'
is when you try your M-y.

martin
[keyboard.c.diff (text/plain, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#26104; Package emacs. (Sat, 08 Apr 2017 22:43:02 GMT) Full text and rfc822 format available.

Message #38 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: Sat, 8 Apr 2017 18:42:11 -0400
On 04/08/2017 04:59 AM, martin rudalics wrote:
> And what would make you that sure that the `handle-switch-frame' event
> was not inserted before you disabled xinput?

I used both yank and then yank-pop after I disabled the xinput. But 
also, I can see that read-event gives switch-frame every time I press 
alt. But you are clearly correct in that the mouse/cursor plays an 
important role, since it only happens when the cursor is in a particular 
position.


>
> Anyway, as a first attempt try to apply the attached patch to keyboard.c
> and tell me what the value of the variable `lispy-switch-frame-source'
> is when you try your M-y.
>
> martin
I changed keyboard.c and rebuilt emacs. The value for 
lispy-switch-frame-source is focus_in_event.





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#26104; Package emacs. (Sun, 09 Apr 2017 06:38:02 GMT) Full text and rfc822 format available.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Jonathan Ganc <jonganc <at> gmail.com>, 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: Sun, 09 Apr 2017 08:37:41 +0200
> I changed keyboard.c and rebuilt emacs. The value for
> lispy-switch-frame-source is focus_in_event.

Same here.  So I suggest you look into your window manager's focus
policy.  It's focus follows mouse on my machine which evidently produces
a focus-in event each time the mouse moves to another frame.

martin




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#26104; Package emacs. (Sat, 15 Apr 2017 09:43:02 GMT) Full text and rfc822 format available.

Message #44 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: Sat, 15 Apr 2017 05:41:54 -0400
You were right.

I found the setting that causes the issue. In CompizConfig (i.e. apt 
package compizconfig-settings-manager), go to Ubuntu Unity Plugin, and 
then, under General, disable "Key to show the menu bar while pressed". 
The problem goes away. (The irony is that I dislike the menu hiding and 
had it disabled anyway).

At the very least, if menu hiding is disabled, so should this key 
shortcut. I will let the Ubuntu people know.

Thanks for your help in tracking this down.

Jonathan


On 04/09/2017 02:37 AM, martin rudalics wrote:
> > I changed keyboard.c and rebuilt emacs. The value for
> > lispy-switch-frame-source is focus_in_event.
>
> Same here.  So I suggest you look into your window manager's focus
> policy.  It's focus follows mouse on my machine which evidently produces
> a focus-in event each time the mouse moves to another frame.
>
> martin





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#26104; Package emacs. (Sat, 15 Apr 2017 14:51:02 GMT) Full text and rfc822 format available.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Jonathan Ganc <jonganc <at> gmail.com>, 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: Sat, 15 Apr 2017 16:50:15 +0200
> I found the setting that causes the issue. In CompizConfig (i.e. apt
> package compizconfig-settings-manager), go to Ubuntu Unity Plugin, and
> then, under General, disable "Key to show the menu bar while
> pressed". The problem goes away. (The irony is that I dislike the menu
> hiding and had it disabled anyway).

Hmm..  I don't understand well (not using Compiz).  Which key is that
and why would it cause a focus-in event when moving the mouse?  Or is
that key the <Alt> key and pressing it causes a focus-in event?  If so,
we should mention that somewhere, either in the manual or in PROBLEMS.

martin




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#26104; Package emacs. (Sat, 15 Apr 2017 15:12:01 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: jonganc <at> gmail.com, 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: Sat, 15 Apr 2017 18:11:24 +0300
> Date: Sat, 15 Apr 2017 16:50:15 +0200
> From: martin rudalics <rudalics <at> gmx.at>
> 
>  > I found the setting that causes the issue. In CompizConfig (i.e. apt
>  > package compizconfig-settings-manager), go to Ubuntu Unity Plugin, and
>  > then, under General, disable "Key to show the menu bar while
>  > pressed". The problem goes away. (The irony is that I dislike the menu
>  > hiding and had it disabled anyway).
> 
> Hmm..  I don't understand well (not using Compiz).  Which key is that
> and why would it cause a focus-in event when moving the mouse?  Or is
> that key the <Alt> key and pressing it causes a focus-in event?

Heh, it looks like they copied the MS-Windows (mis)feature, whereby
tapping the Alt key activates the menu bar, which would indeed require
a focus-in event; seems like some GNU/Linux distros have joined this
lunacy.  In the MS-Windows build, we have w32-pass-alt-to-system to
control that.

(Sometimes it seems to me like GNU/Linux developers have no GUI ideas
of their own, and all they can do is copycat from MS-Windows.)

> If so, we should mention that somewhere, either in the manual or in
> PROBLEMS.

Perhaps we should generalize w32-pass-alt-to-system instead?  Assuming
an application can control this behavior on GNU/Linux, that is.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#26104; Package emacs. (Sat, 15 Apr 2017 19:40:02 GMT) Full text and rfc822 format available.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: jonganc <at> gmail.com, 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: Sat, 15 Apr 2017 21:39:13 +0200
> Heh, it looks like they copied the MS-Windows (mis)feature, whereby
> tapping the Alt key activates the menu bar, which would indeed require
> a focus-in event; seems like some GNU/Linux distros have joined this
> lunacy.  In the MS-Windows build, we have w32-pass-alt-to-system to
> control that.

If I'm not mistaken, on MS-Windows you can activate the menu bar of a
window via the Alt key iff that window has focus already.  I still fail
to understand how pressing the Alt key could transfer focus to another
window.

> Perhaps we should generalize w32-pass-alt-to-system instead?  Assuming
> an application can control this behavior on GNU/Linux, that is.

If Compiz can, Emacs should be able to do that too.

martin




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#26104; Package emacs. (Sat, 15 Apr 2017 20:24:01 GMT) Full text and rfc822 format available.

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

From: Jonathan Ganc <jonganc <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 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: Sat, 15 Apr 2017 16:23:44 -0400
I'm currently trying to understand the issue better, but I think Compiz 
Settings just allows to access to more settings (I think Compiz is part 
of Unity; on my computer, there's always a compiz process). So I think 
it is actually preventing Ubuntu from sending the event when Alt is 
pressed, not intercepting Alt, i.e. it doesn't actively do anything.


On 04/15/2017 03:39 PM, martin rudalics wrote:
> > Heh, it looks like they copied the MS-Windows (mis)feature, whereby
> > tapping the Alt key activates the menu bar, which would indeed require
> > a focus-in event; seems like some GNU/Linux distros have joined this
> > lunacy.  In the MS-Windows build, we have w32-pass-alt-to-system to
> > control that.
>
> If I'm not mistaken, on MS-Windows you can activate the menu bar of a
> window via the Alt key iff that window has focus already.  I still fail
> to understand how pressing the Alt key could transfer focus to another
> window.
>
> > Perhaps we should generalize w32-pass-alt-to-system instead? Assuming
> > an application can control this behavior on GNU/Linux, that is.
>
> If Compiz can, Emacs should be able to do that too.
>
> martin





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#26104; Package emacs. (Sat, 15 Apr 2017 20:34:02 GMT) Full text and rfc822 format available.

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

From: Jonathan Ganc <jonganc <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 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: Sat, 15 Apr 2017 16:33:35 -0400
In particular, setting it in Compiz Settings is equivalent to running this:

dconf write /org/compiz/profiles/unity/plugins/unityshell/show-menu-bar 
"'Disabled'"


On 04/15/2017 03:39 PM, martin rudalics wrote:
> > Heh, it looks like they copied the MS-Windows (mis)feature, whereby
> > tapping the Alt key activates the menu bar, which would indeed require
> > a focus-in event; seems like some GNU/Linux distros have joined this
> > lunacy.  In the MS-Windows build, we have w32-pass-alt-to-system to
> > control that.
>
> If I'm not mistaken, on MS-Windows you can activate the menu bar of a
> window via the Alt key iff that window has focus already.  I still fail
> to understand how pressing the Alt key could transfer focus to another
> window.
>
> > Perhaps we should generalize w32-pass-alt-to-system instead? Assuming
> > an application can control this behavior on GNU/Linux, that is.
>
> If Compiz can, Emacs should be able to do that too.
>
> martin





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#26104; Package emacs. (Sun, 16 Apr 2017 07:16:01 GMT) Full text and rfc822 format available.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Jonathan Ganc <jonganc <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 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: Sun, 16 Apr 2017 09:15:17 +0200
> I'm currently trying to understand the issue better, but I think
> Compiz Settings just allows to access to more settings (I think Compiz
> is part of Unity; on my computer, there's always a compiz process). So
> I think it is actually preventing Ubuntu from sending the event when
> Alt is pressed, not intercepting Alt, i.e. it doesn't actively do
> anything.

Sounds reasonable.  So in order to intercept Alt we would have to look
into how Compiz does it.  Till then we should tell people that and how
they can do it via Compiz (or any other window manager able to do the
same).

martin




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#26104; Package emacs. (Thu, 21 Apr 2022 15:17:01 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Jonathan Ganc <jonganc <at> gmail.com>
Cc: 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: Thu, 21 Apr 2022 17:15:52 +0200
Jonathan Ganc <jonganc <at> gmail.com> writes:

> I found the setting that causes the issue. In CompizConfig (i.e. apt
> package compizconfig-settings-manager), go to Ubuntu Unity Plugin, and
> then, under General, disable "Key to show the menu bar while
> pressed". The problem goes away. (The irony is that I dislike the menu
> hiding and had it disabled anyway).
>
> At the very least, if menu hiding is disabled, so should this key
> shortcut. I will let the Ubuntu people know.

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

Skimming this bug report, it seems like this problem was caused by an
external setting, and there wasn't much we could do about that on the
Emacs side, so I'm closing this bug report.  If that's mistaken, and we
should do something on the Emacs side, please respond to the debbugs
address and we'll reopen.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




bug closed, send any further explanations to 26104 <at> debbugs.gnu.org and Jonathan Ganc <jonganc <at> gmail.com> Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Thu, 21 Apr 2022 15:17:02 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Fri, 20 May 2022 11:24:04 GMT) Full text and rfc822 format available.

This bug report was last modified 1 year and 313 days ago.

Previous Next


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