GNU bug report logs - #61241
29.0.60; Incoherent last_mouse_window (xterm.c) between XInput and XInput 2

Previous Next

To reply to this bug, email your comments to 61241 AT debbugs.gnu.org.
There is no need to reopen the bug first.

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

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

From: Adrián Medraño Calvo <adrian <at> medranocalvo.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.60; Incoherent last_mouse_window (xterm.c) between XInput and
 XInput 2
Date: Thu, 2 Feb 2023 23:28:01 +0100

[Message part 1 (text/plain, inline)]

For the implementation of `mouse-autoselect-window', the entered window
is remembered and then compared when an mouse motion event is received.
Up to Emacs 28, this value was stored in a static local variable named
`last_mouse_window' in the block handling MotionNotify within
`handle_one_xevent'.  With the introduction of XInput 2,
`handle_one_xevent' was adjusted to account for XI_Motion events, with
the oversight that a new local static `last_mouse_window' variable was
declared in the new handler block for XI_Motion.  As a result, when
Emacs receives motion events from XInput and XInput2 sources
alternatively the value of each `last_mouse_window’ differs, leading to
the window under the motion sometimes not being selected, as the
value `last_mouse_window' is out-of-date for the particular XInput
version.

This bug impacts the GNU ELPA package EXWM.  EXWM tries to extrapolate
applicable Emacs functionality to X window management; among others
assigns an Emacs buffer to each managed X window, and positions the X
window over the Emacs window in which the buffer is displayed.  When
`mouse-autoselect-windows’ and the user moves the mouse pointer over one
X window managed by EXWM, this X window receives the mouse events and not
Emacs, therefore the Emacs window is not selected.  In order to overcome
this, EXWM sends a synthetic MotionNotify event to Emacs.

The attached patch fixes the issue.

Thank you,
Adrián Medraño Calvo.

[0001-Fix-mouse-autoselect-window-for-alternating-XInput-a.patch (application/octet-stream, attachment)]

[Message part 3 (text/plain, inline)]

In GNU Emacs 29.0.60 (build 1, x86_64-apple-darwin22.2.0, cairo version
 1.17.6) of 2023-01-26 built on amcmac
Repository revision: f8c95d1a7681e861fc22d2a040cda0ddfe23eff4
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101006
System Description:  macOS 13.2

Configured using:
 'configure --prefix=/Volumes/sys/repos/emacs-cairo/rel
 --without-makeinfo --without-dbus --without-ns --with-x-toolkit=no
 --with-cairo
 PKG_CONFIG_PATH=/opt/X11/lib/pkgconfig:/usr/local/opt/freetype/lib/pkgconfig:/usr/local/opt/fontconfig/lib/pkgconfig:/usr/local/opt/ncurses/lib/pkgconfig:/usr/local/opt/libxml2/lib/pkgconfig:/usr/local/Cellar/jpeg/9d/lib/pkgconfig:/usr/local/Cellar/libtiff/4.3.0/lib/pkgconfig:/usr/local/opt/harfbuzz/lib/pkgconfig/:/usr/local/opt/harfbuzz/lib/pkgconfig/
 'CFLAGS=-Og -g3' --without-jpeg --without-gif --without-xpm
 --without-tiff'

Configured features:
ACL CAIRO FREETYPE GLIB GMP GNUTLS GSETTINGS HARFBUZZ JSON LCMS2 LIBXML2
MODULES NOTIFY KQUEUE OLDXMENU PDUMPER PNG RSVG SQLITE3 THREADS WEBP X11
XDBE XIM XINPUT2 ZLIB

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

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-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
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-util text-property-search time-date subr-x mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
cl-loaddefs cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util
mail-prsvr mail-utils rmc iso-transl tooltip cconv eldoc paren electric
uniquify ediff-hook vc-hooks lisp-float-type elisp-mode 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 lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine 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 emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads kqueue lcms2 dynamic-setting
system-font-setting font-render-setting cairo xinput2 x multi-tty
make-network-process emacs)

Memory information:
((conses 16 38318 8147)
 (symbols 48 5108 0)
 (strings 32 12656 2131)
 (string-bytes 1 362604)
 (vectors 16 10252)
 (vector-slots 8 147251 15877)
 (floats 8 42 19)
 (intervals 56 263 0)
 (buffers 976 10))

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Adrián Medraño Calvo <adrian <at> medranocalvo.com>, Po
 Lu <luangruo <at> yahoo.com>
Cc: 61241 <at> debbugs.gnu.org
Subject: Re: bug#61241: 29.0.60;
 Incoherent last_mouse_window (xterm.c) between XInput and XInput 2
Date: Sat, 04 Feb 2023 10:25:12 +0200

> From: Adrián Medraño Calvo
>  <adrian <at> medranocalvo.com>
> Date: Thu, 2 Feb 2023 23:28:01 +0100
> 
> For the implementation of `mouse-autoselect-window', the entered window
> is remembered and then compared when an mouse motion event is received.
> Up to Emacs 28, this value was stored in a static local variable named
> `last_mouse_window' in the block handling MotionNotify within
> `handle_one_xevent'.  With the introduction of XInput 2,
> `handle_one_xevent' was adjusted to account for XI_Motion events, with
> the oversight that a new local static `last_mouse_window' variable was
> declared in the new handler block for XI_Motion.  As a result, when
> Emacs receives motion events from XInput and XInput2 sources
> alternatively the value of each `last_mouse_window’ differs, leading to
> the window under the motion sometimes not being selected, as the
> value `last_mouse_window' is out-of-date for the particular XInput
> version.
> 
> This bug impacts the GNU ELPA package EXWM.  EXWM tries to extrapolate
> applicable Emacs functionality to X window management; among others
> assigns an Emacs buffer to each managed X window, and positions the X
> window over the Emacs window in which the buffer is displayed.  When
> `mouse-autoselect-windows’ and the user moves the mouse pointer over one
> X window managed by EXWM, this X window receives the mouse events and not
> Emacs, therefore the Emacs window is not selected.  In order to overcome
> this, EXWM sends a synthetic MotionNotify event to Emacs.
> 
> The attached patch fixes the issue.
> 
> Thank you,
> Adrián Medraño Calvo.
> 
> From e16d6ddbfdc4110fbbbcf763cff5a72b0f0df92c Mon Sep 17 00:00:00 2001
> Message-Id: <e16d6ddbfdc4110fbbbcf763cff5a72b0f0df92c.1675376734.git.adrian <at> medranocalvo.com>
> From: =?UTF-8?q?Adri=C3=A1n=20Medra=C3=B1o=20Calvo?=
>  <adrian <at> medranocalvo.com>
> Date: Wed, 1 Feb 2023 00:00:00 +0000
> Subject: [PATCH] Fix `mouse-autoselect-window' for alternating XInput and
>  XInput 2 events
> 
> * src/xterm.c (handle_one_xevent): Move `last_mouse_window' to
> main function scope to share value between XInput and XInput 2
> handlers.
> ---
>  src/xterm.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/src/xterm.c b/src/xterm.c
> index 6a4b84babe4..dd20c8c7fe5 100644
> --- a/src/xterm.c
> +++ b/src/xterm.c
> @@ -18364,6 +18364,9 @@ handle_one_xevent (struct x_display_info *dpyinfo,
>    GdkDisplay *gdpy = gdk_x11_lookup_xdisplay (dpyinfo->display);
>  #endif
>    int dx, dy;
> +  /* Holds the last window the mouse moved over, used for
> +     `mouse-autoselect-window' */
> +  static Lisp_Object last_mouse_window;
>  
>    /* Avoid warnings when SAFE_ALLOCA is not actually used.  */
>  #if defined HAVE_XINPUT2 || defined HAVE_XKB || defined HAVE_X_I18N
> @@ -20677,8 +20680,6 @@ handle_one_xevent (struct x_display_info *dpyinfo,
>  		&& (f == XFRAME (selected_frame)
>  		    || !NILP (focus_follows_mouse)))
>  	      {
> -		static Lisp_Object last_mouse_window;
> -
>  		if (xmotion.window != FRAME_X_WINDOW (f))
>  		  {
>  		    x_translate_coordinates (f, xmotion.x_root, xmotion.y_root,
> @@ -22587,7 +22588,6 @@ handle_one_xevent (struct x_display_info *dpyinfo,
>  		      && (f == XFRAME (selected_frame)
>  			  || !NILP (focus_follows_mouse)))
>  		    {
> -		      static Lisp_Object last_mouse_window;
>  		      Lisp_Object window = window_from_coordinates (f, ev.x, ev.y, 0, false, false);
>  
>  		      /* A window will be autoselected only when it is not
> -- 
> 2.39.1

Po Lu, any comments, or should this go in?

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

From: Po Lu <luangruo <at> yahoo.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 61241 <at> debbugs.gnu.org,
 Adrián Medraño Calvo <adrian <at> medranocalvo.com>
Subject: Re: bug#61241: 29.0.60; Incoherent last_mouse_window (xterm.c)
 between XInput and XInput 2
Date: Sat, 04 Feb 2023 16:43:31 +0800

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Adrián Medraño Calvo
>>  <adrian <at> medranocalvo.com>
>> Date: Thu, 2 Feb 2023 23:28:01 +0100
>> 
>> For the implementation of `mouse-autoselect-window', the entered window
>> is remembered and then compared when an mouse motion event is received.
>> Up to Emacs 28, this value was stored in a static local variable named
>> `last_mouse_window' in the block handling MotionNotify within
>> `handle_one_xevent'.  With the introduction of XInput 2,
>> `handle_one_xevent' was adjusted to account for XI_Motion events, with
>> the oversight that a new local static `last_mouse_window' variable was
>> declared in the new handler block for XI_Motion.  As a result, when
>> Emacs receives motion events from XInput and XInput2 sources
>> alternatively the value of each `last_mouse_window’ differs, leading to
>> the window under the motion sometimes not being selected, as the
>> value `last_mouse_window' is out-of-date for the particular XInput
>> version.
>> 
>> This bug impacts the GNU ELPA package EXWM.  EXWM tries to extrapolate
>> applicable Emacs functionality to X window management; among others
>> assigns an Emacs buffer to each managed X window, and positions the X
>> window over the Emacs window in which the buffer is displayed.  When
>> `mouse-autoselect-windows’ and the user moves the mouse pointer over one
>> X window managed by EXWM, this X window receives the mouse events and not
>> Emacs, therefore the Emacs window is not selected.  In order to overcome
>> this, EXWM sends a synthetic MotionNotify event to Emacs.
>> 
>> The attached patch fixes the issue.

Thanks.  But first of all, Emacs is not at all prepared to receive both
MotionNotify events and XI_Motion events on a frame at the same time in
other areas as well, such as focus tracking.

This is not possible under an X server.

So EXWM should send XI_Motion events when the X server supports XInput 2
(they are Generic Events, and XCB lets you send them, though not Xlib
because nobody has written a working event to wire function yet.)

Or alternatively, why doesn't exwm just focus the window itself?

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

From: Adrián Medraño Calvo <adrian <at> medranocalvo.com>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 61241 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#61241: 29.0.60;
 Incoherent last_mouse_window (xterm.c) between XInput and XInput 2
Date: Sun, 5 Feb 2023 20:04:42 +0100


Please see below.

> Am 04.02.2023 um 09:45 schrieb Po Lu <luangruo <at> yahoo.com>:
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
>>> From: Adrián Medraño Calvo
>>> <adrian <at> medranocalvo.com>
>>> Date: Thu, 2 Feb 2023 23:28:01 +0100
>>> For the implementation of `mouse-autoselect-window', the entered window
>>> is remembered and then compared when an mouse motion event is received.
>>> Up to Emacs 28, this value was stored in a static local variable named
>>> `last_mouse_window' in the block handling MotionNotify within
>>> `handle_one_xevent'.  With the introduction of XInput 2,
>>> `handle_one_xevent' was adjusted to account for XI_Motion events, with
>>> the oversight that a new local static `last_mouse_window' variable was
>>> declared in the new handler block for XI_Motion.  As a result, when
>>> Emacs receives motion events from XInput and XInput2 sources
>>> alternatively the value of each `last_mouse_window’ differs, leading to
>>> the window under the motion sometimes not being selected, as the
>>> value `last_mouse_window' is out-of-date for the particular XInput
>>> version.
>>> This bug impacts the GNU ELPA package EXWM.  EXWM tries to extrapolate
>>> applicable Emacs functionality to X window management; among others
>>> assigns an Emacs buffer to each managed X window, and positions the X
>>> window over the Emacs window in which the buffer is displayed.  When
>>> `mouse-autoselect-windows’ and the user moves the mouse pointer over one
>>> X window managed by EXWM, this X window receives the mouse events and not
>>> Emacs, therefore the Emacs window is not selected.  In order to overcome
>>> this, EXWM sends a synthetic MotionNotify event to Emacs.
>>> The attached patch fixes the issue.
> 
> Thanks.  But first of all, Emacs is not at all prepared to receive both
> MotionNotify events and XI_Motion events on a frame at the same time in
> other areas as well, such as focus tracking.
> 
> This is not possible under an X server.

Thank you. I thought already about fixing this in EXWM by sending the XI_Motion event when Emacs uses XInput 2 (as you propose below), but thought that other users might be in a similar situation. For example, a user using xdotool (I must say that I don't know whether xdotool relies on XInput, XInput 2, XTest or something else, but for the sake of this example please assume the former) would observe the same behaviour as us.

If I understand correctly, an XInput 2 enabled Emacs must handle regular events as well because some of its frames might be in terminals supporting only Xinput 1. If that's the case, would it be possible to drop/reject corresponding regular events (e.g. MotionNotifiy) on terminals supporting XInput 2? If that's not possible, I’d say it’s better applying the patch (or similar) so that, even while unsupported, we do a best effort in reducing inconsistency.

> So EXWM should send XI_Motion events when the X server supports XInput 2
> (they are Generic Events, and XCB lets you send them, though not Xlib
> because nobody has written a working event to wire function yet.)

I'll implement your suggestion in EXWM shortly, in any case before Emacs 29 is released. How can I detect whether Emacs uses XInput 2 in a particular terminal?

> Or alternatively, why doesn't exwm just focus the window itself?

(I’m not sure whether I understand your question, please clarify if you think I missed it.) Just focusing the X window (and selecting the related Emacs window) is not enough for integrating `mouse-autoselect-window', precisely because `last_mouse_window' gets out-of-sync, leading to the user being unable to select back the last Emacs window by moving the mouse over it. A possible solution to this would be to expose `last_mouse_window' to Lisp (e.g. `mouse-autoselect-last-window'); presumably EXWM could then set its value as part of the above steps and have focus follow the pointer. I’d say this is my preferred solution, what do you think about this?

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

From: Po Lu <luangruo <at> yahoo.com>
To: Adrián Medraño Calvo <adrian <at> medranocalvo.com>
Cc: 61241 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#61241: 29.0.60; Incoherent last_mouse_window (xterm.c)
 between XInput and XInput 2
Date: Mon, 06 Feb 2023 09:40:50 +0800

Adrián Medraño Calvo <adrian <at> medranocalvo.com> writes:

> Thank you. I thought already about fixing this in EXWM by sending the
> XI_Motion event when Emacs uses XInput 2 (as you propose below), but
> thought that other users might be in a similar situation. For example,
> a user using xdotool (I must say that I don't know whether xdotool
> relies on XInput, XInput 2, XTest or something else, but for the sake
> of this example please assume the former) would observe the same
> behaviour as us.

These tools should use the record or test extensions, which will not
have these problems.

> If I understand correctly, an XInput 2 enabled Emacs must handle
> regular events as well because some of its frames might be in
> terminals supporting only Xinput 1. If that's the case, would it be
> possible to drop/reject corresponding regular events
> (e.g. MotionNotifiy) on terminals supporting XInput 2? If that's not
> possible, I’d say it’s better applying the patch (or similar) so that,
> even while unsupported, we do a best effort in reducing inconsistency.

XInput 1.x is not supported by Emacs.  You probably mean the X11 core
protocol.

It is ok for MotionNotify events to arrive on a display that has not
selected for input extension events, since Emacs does not keep track of
much state globally across displays.

But once they do on a display that has, then a lot can go wrong.

> I'll implement your suggestion in EXWM shortly, in any case before
> Emacs 29 is released. How can I detect whether Emacs uses XInput 2 in
> a particular terminal?

The function `x-server-input-extension-version'.

> (I’m not sure whether I understand your question, please clarify if
> you think I missed it.) Just focusing the X window (and selecting the
> related Emacs window) is not enough for integrating
> `mouse-autoselect-window', precisely because `last_mouse_window' gets
> out-of-sync, leading to the user being unable to select back the last
> Emacs window by moving the mouse over it. A possible solution to this
> would be to expose `last_mouse_window' to Lisp
> (e.g. `mouse-autoselect-last-window'); presumably EXWM could then set
> its value as part of the above steps and have focus follow the
> pointer. I’d say this is my preferred solution, what do you think
> about this?

Sounds reasonable, except it is too late in the Emacs 29 release cycle
to implement this there.

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

From: Adrián Medraño Calvo <adrian <at> medranocalvo.com>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 61241 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#61241: 29.0.60; Incoherent last_mouse_window (xterm.c)
 between XInput and XInput 2
Date: Tue, 22 Aug 2023 07:45:53 +0200

[Message part 1 (text/plain, inline)]

Dear Po Lu,

> On 6. Feb 2023, at 02:40, Po Lu <luangruo <at> yahoo.com> wrote:
> 
> Adrián Medraño Calvo <adrian <at> medranocalvo.com> writes:
> 
>> Thank you. I thought already about fixing this in EXWM by sending the
>> XI_Motion event when Emacs uses XInput 2 (as you propose below), but
>> thought that other users might be in a similar situation. For example,
>> a user using xdotool (I must say that I don't know whether xdotool
>> relies on XInput, XInput 2, XTest or something else, but for the sake
>> of this example please assume the former) would observe the same
>> behaviour as us.
> 
> These tools should use the record or test extensions, which will not
> have these problems.

I’ve tried implementing your suggestion to send an XI_Motion event to Emacs when the mouse enters the X window managed by EXWM—to no avail:

1. Using SendEvent: XI2 events are GenericEvents, Xorg disallows sending GenericEvents within SendEvent.  The following seem to be the cause:
- https://gitlab.freedesktop.org/xorg/xserver/-/blob/master/dix/events.c#L5517, and especially
- https://gitlab.freedesktop.org/xorg/xserver/-/blob/master/dix/events.c#L5541

2. Using XTest: although undocumented (as far as I could see), XTest does support sending XI device events.  The issue is that EXWM wants to, when entering a managed X window, send XI_Motion events to Emacs as well so as to trick it into thinking that the pointer entered the Emacs window corresponding to the mentioned X window; which marks this Emacs window the last Emacs window the pointer was over.  The last think is critical for focus-follows-mouse to work on EXWM. The obstacle I find with XTest is that XTest just mimics moving the pointer so, when moving the pointer to an X window and then using XTest to simulate moving the pointer there (again), nothing changes: the XI_Motion events are again sent to this topmost X Window.  I couldn’t think of a way of having the XTest events lead to XI_Motion reaching Emacs in such a situation. 

3. I also tried using XWrapPointer which of course does not help as it generates no motion events.

Can you think of a way forward?

>> If I understand correctly, an XInput 2 enabled Emacs must handle
>> regular events as well because some of its frames might be in
>> terminals supporting only Xinput 1. If that's the case, would it be
>> possible to drop/reject corresponding regular events
>> (e.g. MotionNotifiy) on terminals supporting XInput 2? If that's not
>> possible, I’d say it’s better applying the patch (or similar) so that,
>> even while unsupported, we do a best effort in reducing inconsistency.
> 
> XInput 1.x is not supported by Emacs.  You probably mean the X11 core
> protocol.
> 
> It is ok for MotionNotify events to arrive on a display that has not
> selected for input extension events, since Emacs does not keep track of
> much state globally across displays.
> 
> But once they do on a display that has, then a lot can go wrong.
> 
>> I'll implement your suggestion in EXWM shortly, in any case before
>> Emacs 29 is released. How can I detect whether Emacs uses XInput 2 in
>> a particular terminal?
> 
> The function `x-server-input-extension-version'.
> 
>> (I’m not sure whether I understand your question, please clarify if
>> you think I missed it.) Just focusing the X window (and selecting the
>> related Emacs window) is not enough for integrating
>> `mouse-autoselect-window', precisely because `last_mouse_window' gets
>> out-of-sync, leading to the user being unable to select back the last
>> Emacs window by moving the mouse over it. A possible solution to this
>> would be to expose `last_mouse_window' to Lisp
>> (e.g. `mouse-autoselect-last-window'); presumably EXWM could then set
>> its value as part of the above steps and have focus follow the
>> pointer. I’d say this is my preferred solution, what do you think
>> about this?
> 
> Sounds reasonable, except it is too late in the Emacs 29 release cycle
> to implement this there.

I prepared a patch (attached below) introducing a new lisp variable holding the last "mouse-autoselected” window.  With this patch EXWM can simply select the Emacs window corresponding to the managed X window and set it as last “mouse-autoselected” window; mouse-autoselect works normally after that.  No more sending Motion events.

Using a single variable introduces a significant change, though: when `mouse-autoselect-window’ is enabled and emacs runs in different terminals, “mouse-autoselecting” a window on a terminal changes the last “mouse-autoselected” window for all other terminals.  Slightly moving the mouse in a different terminal (within a single Emacs window) will “mouse-autoselect” that window, whereas that would not have been the case before this patch, as the last “mouse-autoselected” window was terminal-specific.  It’s not clear to me whether this behaviour will be beneficial, neutral or unacceptable.  Moreover, this behaviour is consistent with the behaviour introduced in the first patch I sent, where I proposed to merge the last “mouse-autoselected” window for Motion and XI_Motion events (other terminals were not affected).

Please let me know your thoughts.

Regards,
Adrián.

[0001-Expose-last-window-under-pointer-to-Lisp.patch (application/octet-stream, attachment)]

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

From: Po Lu <luangruo <at> yahoo.com>
To: Adrián Medraño Calvo <adrian <at> medranocalvo.com>
Cc: 61241 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#61241: 29.0.60; Incoherent last_mouse_window (xterm.c)
 between XInput and XInput 2
Date: Tue, 22 Aug 2023 14:59:00 +0800

Adrián Medraño Calvo <adrian <at> medranocalvo.com> writes:

> I prepared a patch (attached below) introducing a new lisp variable
> holding the last "mouse-autoselected” window.  With this patch EXWM
> can simply select the Emacs window corresponding to the managed X
> window and set it as last “mouse-autoselected” window;
> mouse-autoselect works normally after that.  No more sending Motion
> events.
>
> Using a single variable introduces a significant change, though: when
> `mouse-autoselect-window’ is enabled and emacs runs in different
> terminals, “mouse-autoselecting” a window on a terminal changes the
> last “mouse-autoselected” window for all other terminals.  Slightly
> moving the mouse in a different terminal (within a single Emacs
> window) will “mouse-autoselect” that window, whereas that would not
> have been the case before this patch, as the last “mouse-autoselected”
> window was terminal-specific.  It’s not clear to me whether this
> behaviour will be beneficial, neutral or unacceptable.  Moreover, this
> behaviour is consistent with the behaviour introduced in the first
> patch I sent, where I proposed to merge the last “mouse-autoselected”
> window for Motion and XI_Motion events (other terminals were not
> affected).

Thanks.  Taking into account your experiences with the TEST extension,
I'm inclined towards believing that such a change is TRT, but the
variable should be made terminal-local instead.  (Emacs Lisp does
provide such a facility.)

Also, there are a few difficulties with the patch you attached.  First
of all, it obsoletes an existing variable without due reason, and that
should be avoided.  Secondly, :version specifiers within the patch
should be revised to mention Emacs 30, since such a large change is not
apposite for the release branch.

Finally, you missed the new terminal backend introduced in Emacs 30,
src/androidterm.c.

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

From: Adrián Medraño Calvo <adrian <at> medranocalvo.com>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 61241 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#61241: 29.0.60; Incoherent last_mouse_window (xterm.c)
 between XInput and XInput 2
Date: Tue, 13 May 2025 17:49:16 +0200

[Message part 1 (text/plain, inline)]

> On 22. Aug 2023, at 08:59, Po Lu <luangruo <at> yahoo.com> wrote:
> 
> Thanks.  Taking into account your experiences with the TEST extension,
> I'm inclined towards believing that such a change is TRT, but the
> variable should be made terminal-local instead.  (Emacs Lisp does
> provide such a facility.)
> 
> Also, there are a few difficulties with the patch you attached.  First
> of all, it obsoletes an existing variable without due reason, and that
> should be avoided.  Secondly, :version specifiers within the patch
> should be revised to mention Emacs 30, since such a large change is not
> apposite for the release branch.
> 
> Finally, you missed the new terminal backend introduced in Emacs 30,
> src/androidterm.c.

Dear Po Lu,

in the summer of 2024 I implemented a patch incorporating your suggestions.
A couple of days ago I had a new look with the intention of finally submitting
it.  The patch corrects most of the issues you pointed out back then: nothing
is touched in lisp/window.el, the variable is made terminal-local and it is
implemented for androidterm as well.  I don’t know how to indicate the :version
for this terminal-local variable in the C code –or whether it’s possible–,
please indicate how to do so (or simply edit the patch, as you prefer).

A surprise emerged while rebasing to master: I discovered that since commit 2e8ef0910412aef8f9f1beba7c942473ad8602bb ("Protect against GCing of
last_mouse_window”) all `last_mouse_window` of different terminals were merged
into a single global variable.  This is equivalent to my proposal in "Expose last
window under pointer to Lisp” of 2023-08-22.  This commit solves the original
issue and, if you find it satisfactory, would allow to happily close this ticket.

If you still think that implementing it as a terminal-local variable is necessary
or preferable, I’m attaching the patch I described above.  Note that I revert the
changes introduced in 2e8ef09104 in my patch (please review attentively).

Thank you for your patience and, as always, thank you for your work in Emacs.

Kind regards,
Adrián.

[0001-Expose-last-entered-window-to-Lisp.patch (application/octet-stream, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: luangruo <at> yahoo.com, Adrián Medraño Calvo
 <adrian <at> medranocalvo.com>
Cc: 61241 <at> debbugs.gnu.org
Subject: Re: bug#61241: 29.0.60; Incoherent last_mouse_window (xterm.c)
 between XInput and XInput 2
Date: Sat, 24 May 2025 12:07:27 +0300

Po Lu, any comments?

> From: Adrián Medraño Calvo <adrian <at> medranocalvo.com>
> Date: Tue, 13 May 2025 17:49:16 +0200
> Cc: Eli Zaretskii <eliz <at> gnu.org>,
>  61241 <at> debbugs.gnu.org
> 
> > On 22. Aug 2023, at 08:59, Po Lu <luangruo <at> yahoo.com> wrote:
> > 
> > Thanks.  Taking into account your experiences with the TEST extension,
> > I'm inclined towards believing that such a change is TRT, but the
> > variable should be made terminal-local instead.  (Emacs Lisp does
> > provide such a facility.)
> > 
> > Also, there are a few difficulties with the patch you attached.  First
> > of all, it obsoletes an existing variable without due reason, and that
> > should be avoided.  Secondly, :version specifiers within the patch
> > should be revised to mention Emacs 30, since such a large change is not
> > apposite for the release branch.
> > 
> > Finally, you missed the new terminal backend introduced in Emacs 30,
> > src/androidterm.c.
> 
> Dear Po Lu,
> 
> in the summer of 2024 I implemented a patch incorporating your suggestions.
> A couple of days ago I had a new look with the intention of finally submitting
> it.  The patch corrects most of the issues you pointed out back then: nothing
> is touched in lisp/window.el, the variable is made terminal-local and it is
> implemented for androidterm as well.  I don’t know how to indicate the :version
> for this terminal-local variable in the C code –or whether it’s possible–,
> please indicate how to do so (or simply edit the patch, as you prefer).
> 
> A surprise emerged while rebasing to master: I discovered that since commit 2e8ef0910412aef8f9f1beba7c942473ad8602bb ("Protect against GCing of
> last_mouse_window”) all `last_mouse_window` of different terminals were merged
> into a single global variable.  This is equivalent to my proposal in "Expose last
> window under pointer to Lisp” of 2023-08-22.  This commit solves the original
> issue and, if you find it satisfactory, would allow to happily close this ticket.
> 
> If you still think that implementing it as a terminal-local variable is necessary
> or preferable, I’m attaching the patch I described above.  Note that I revert the
> changes introduced in 2e8ef09104 in my patch (please review attentively).
> 
> Thank you for your patience and, as always, thank you for your work in Emacs.
> 
> Kind regards,
> Adrián.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: luangruo <at> yahoo.com
Cc: 61241 <at> debbugs.gnu.org, adrian <at> medranocalvo.com
Subject: Re: bug#61241: 29.0.60;
 Incoherent last_mouse_window (xterm.c) between XInput and XInput 2
Date: Sat, 07 Jun 2025 11:20:59 +0300

Ping!  Po Lu, please respond.

> Cc: 61241 <at> debbugs.gnu.org
> Date: Sat, 24 May 2025 12:07:27 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> Po Lu, any comments?
> 
> > From: Adrián Medraño Calvo <adrian <at> medranocalvo.com>
> > Date: Tue, 13 May 2025 17:49:16 +0200
> > Cc: Eli Zaretskii <eliz <at> gnu.org>,
> >  61241 <at> debbugs.gnu.org
> > 
> > > On 22. Aug 2023, at 08:59, Po Lu <luangruo <at> yahoo.com> wrote:
> > > 
> > > Thanks.  Taking into account your experiences with the TEST extension,
> > > I'm inclined towards believing that such a change is TRT, but the
> > > variable should be made terminal-local instead.  (Emacs Lisp does
> > > provide such a facility.)
> > > 
> > > Also, there are a few difficulties with the patch you attached.  First
> > > of all, it obsoletes an existing variable without due reason, and that
> > > should be avoided.  Secondly, :version specifiers within the patch
> > > should be revised to mention Emacs 30, since such a large change is not
> > > apposite for the release branch.
> > > 
> > > Finally, you missed the new terminal backend introduced in Emacs 30,
> > > src/androidterm.c.
> > 
> > Dear Po Lu,
> > 
> > in the summer of 2024 I implemented a patch incorporating your suggestions.
> > A couple of days ago I had a new look with the intention of finally submitting
> > it.  The patch corrects most of the issues you pointed out back then: nothing
> > is touched in lisp/window.el, the variable is made terminal-local and it is
> > implemented for androidterm as well.  I don’t know how to indicate the :version
> > for this terminal-local variable in the C code –or whether it’s possible–,
> > please indicate how to do so (or simply edit the patch, as you prefer).
> > 
> > A surprise emerged while rebasing to master: I discovered that since commit 2e8ef0910412aef8f9f1beba7c942473ad8602bb ("Protect against GCing of
> > last_mouse_window”) all `last_mouse_window` of different terminals were merged
> > into a single global variable.  This is equivalent to my proposal in "Expose last
> > window under pointer to Lisp” of 2023-08-22.  This commit solves the original
> > issue and, if you find it satisfactory, would allow to happily close this ticket.
> > 
> > If you still think that implementing it as a terminal-local variable is necessary
> > or preferable, I’m attaching the patch I described above.  Note that I revert the
> > changes introduced in 2e8ef09104 in my patch (please review attentively).
> > 
> > Thank you for your patience and, as always, thank you for your work in Emacs.
> > 
> > Kind regards,
> > Adrián.
> 
> 
> 
> 

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

From: Po Lu <luangruo <at> yahoo.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 61241 <at> debbugs.gnu.org,
 Adrián Medraño Calvo <adrian <at> medranocalvo.com>
Subject: Re: bug#61241: 29.0.60; Incoherent last_mouse_window (xterm.c)
 between XInput and XInput 2
Date: Sat, 07 Jun 2025 21:34:30 +0800

Eli Zaretskii <eliz <at> gnu.org> writes:

> Po Lu, any comments?

I believe it should be alright to close this ticket now.

P.S. I anticipate being mostly unavailable for Emacs development over
the course of this month.  I'll try to revisit all of the correspondence
I have missed at the close of this period.  My apologies.

Message #40 received at 61241-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 61241-done <at> debbugs.gnu.org, adrian <at> medranocalvo.com
Subject: Re: bug#61241: 29.0.60; Incoherent last_mouse_window (xterm.c)
 between XInput and XInput 2
Date: Sat, 14 Jun 2025 17:01:20 +0300

> From: Po Lu <luangruo <at> yahoo.com>
> Cc: Adrián Medraño Calvo <adrian <at> medranocalvo.com>,
>   61241 <at> debbugs.gnu.org
> Date: Sat, 07 Jun 2025 21:34:30 +0800
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Po Lu, any comments?
> 
> I believe it should be alright to close this ticket now.

Done.

Previous Next

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