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

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

[Jonathan Ganc]

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

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

[martin rudalics]

 > 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

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

[Jonathan Ganc]

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

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

[martin rudalics]

 > 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

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

[martin rudalics]

 > 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

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

[Jonathan Ganc]

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
>

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

[martin rudalics]

 > 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

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

[Jonathan Ganc]

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.

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

[martin rudalics]

 > 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

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

[Jonathan Ganc]

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

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

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 410 bytes --]

 > 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

[-- Attachment #2: keyboard.c.diff --]
[-- Type: text/plain, Size: 3608 bytes --]

diff --git a/src/keyboard.c b/src/keyboard.c
index 3e50142..f3a9dcf 100644
--- a/src/keyboard.c
+++ b/src/keyboard.c
@@ -3481,6 +3481,7 @@ static Lisp_Object kbd_buffer_get_event (KBOARD **kbp, bool *used_mouse_menu,

 	  if (single_kboard && kb != current_kboard)
 	    {
+	      Vlispy_switch_frame_source = Qkbd_buffer_store_buffered_event;
 	      kset_kbd_queue
 		(kb, list2 (make_lispy_switch_frame (event->ie.frame_or_window),
 			    make_number (c)));
@@ -4024,7 +4025,10 @@ static Lisp_Object kbd_buffer_get_event (KBOARD **kbp, bool *used_mouse_menu,
 #endif
               !EQ (frame, internal_last_event_frame)
               && !EQ (frame, selected_frame))
-            obj = make_lispy_switch_frame (frame);
+	    {
+	      Vlispy_switch_frame_source = Qfocus_in_event;
+	      obj = make_lispy_switch_frame (frame);
+	    }
           else
             obj = make_lispy_focus_in (frame);

@@ -4100,7 +4104,10 @@ static Lisp_Object kbd_buffer_get_event (KBOARD **kbp, bool *used_mouse_menu,

 	  if (! EQ (frame, internal_last_event_frame)
 	      && !EQ (frame, selected_frame))
-	    obj = make_lispy_switch_frame (frame);
+	    {
+	      Vlispy_switch_frame_source = Qdifferent_frame;
+	      obj = make_lispy_switch_frame (frame);
+	    }
 	  internal_last_event_frame = frame;

 	  /* If we didn't decide to make a switch-frame event, go ahead
@@ -4171,7 +4178,10 @@ static Lisp_Object kbd_buffer_get_event (KBOARD **kbp, bool *used_mouse_menu,

 	  if (! EQ (frame, internal_last_event_frame)
 	      && !EQ (frame, selected_frame))
-	    obj = make_lispy_switch_frame (frame);
+	    {
+	      Vlispy_switch_frame_source = Qmouse_track;
+	      obj = make_lispy_switch_frame (frame);
+	    }
 	  internal_last_event_frame = frame;
 	}

@@ -9169,6 +9179,7 @@ static void process_tool_bar_item (Lisp_Object, Lisp_Object, Lisp_Object,
 		  {
 		    Lisp_Object frame;
 		    XSETFRAME (frame, interrupted_frame);
+		    Vlispy_switch_frame_source = Qread_key_sequence;
 		    kset_kbd_queue
 		      (interrupted_kboard,
 		       Fcons (make_lispy_switch_frame (frame),
@@ -10498,9 +10509,11 @@ shows the events before all translations (except for input methods).

   if (FRAMEP (internal_last_event_frame)
       && !EQ (internal_last_event_frame, selected_frame))
-    do_switch_frame (make_lispy_switch_frame (internal_last_event_frame),
+    {
+      Vlispy_switch_frame_source = Qquit_throw_to_read_char;
+      do_switch_frame (make_lispy_switch_frame (internal_last_event_frame),
 		     0, 0, Qnil);
-
+    }
   sys_longjmp (getcjmp, 1);
 }
 \f
@@ -11242,6 +11255,13 @@ struct event_head
   help_form_saved_window_configs = Qnil;
   staticpro (&help_form_saved_window_configs);

+  DEFSYM (Qkbd_buffer_store_buffered_event, "kbd_buffer_store_buffered_event");
+  DEFSYM (Qfocus_in_event, "focus_in_event");
+  DEFSYM (Qdifferent_frame, "different_frame");
+  DEFSYM (Qmouse_track, "mouse_track");
+  DEFSYM (Qread_key_sequence, "read_key_sequence");
+  DEFSYM (Qquit_throw_to_read_char, "quit_throw_to_read_char");
+
   defsubr (&Scurrent_idle_time);
   defsubr (&Sevent_symbol_parse_modifiers);
   defsubr (&Sevent_convert_list);
@@ -11833,6 +11853,11 @@ shutdown when Emacs receives a fatal signal (e.g., a crash).
                Vwhile_no_input_ignore_events,
                doc: /* Ignored events from while-no-input.  */);
   Vwhile_no_input_ignore_events = Qnil;
+
+  DEFVAR_LISP ("lispy-switch-frame-source",
+               Vlispy_switch_frame_source,
+               doc: /* Source of last lispy-switch-frame event.  */);
+  Vlispy_switch_frame_source = Qnil;
 }

 void

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

[Jonathan Ganc]

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.

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

[martin rudalics]

 > 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

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

[Jonathan Ganc]

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

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

[martin rudalics]

 > 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

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

[Eli Zaretskii]

> Date: Sat, 15 Apr 2017 16:50:15 +0200
> From: martin rudalics <rudalics@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.

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

[martin rudalics]

 > 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

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

[Jonathan Ganc]

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

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

[martin rudalics]

 > 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

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

[Jonathan Ganc]

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

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

[Lars Ingebrigtsen]

Jonathan Ganc <jonganc@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