[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#61241: 29.0.60; Incoherent last_mouse_window (xterm.c) between XInpu
From: |
Po Lu |
Subject: |
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 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
Adrián Medraño Calvo <adrian@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.