GNU bug report logs -
#61241
29.0.60; Incoherent last_mouse_window (xterm.c) between XInput and XInput 2
Previous Next
Full log
Message #17 received at 61241 <at> debbugs.gnu.org (full text, mbox):
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.
This bug report was last modified 37 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.