From: "Adrián Medraño Calvo" <adrian@medranocalvo.com>
To: Po Lu <luangruo@yahoo.com>
Cc: 61241@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>
Subject: 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 [thread overview]
Message-ID: <C8F43B70-06CC-4745-9044-524CF8E74F34@medranocalvo.com> (raw)
In-Reply-To: <16B04B25-8EB8-4967-947B-C03DF3690ADF@medranocalvo.com>
Please see below.
> Am 04.02.2023 um 09:45 schrieb Po Lu <luangruo@yahoo.com>:
> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Adrián Medraño Calvo
>>> <adrian@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?
next prev parent reply other threads:[~2023-02-05 19:04 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-02 22:28 bug#61241: 29.0.60; Incoherent last_mouse_window (xterm.c) between XInput and XInput 2 Adrián Medraño Calvo
2023-02-04 8:25 ` Eli Zaretskii
2023-02-04 8:43 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-02-05 19:04 ` Adrián Medraño Calvo [this message]
2023-02-06 1:40 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-22 5:45 ` Adrián Medraño Calvo
2023-08-22 6:59 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=C8F43B70-06CC-4745-9044-524CF8E74F34@medranocalvo.com \
--to=adrian@medranocalvo.com \
--cc=61241@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=luangruo@yahoo.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).