exwm
exwm copied to clipboard
ch11ng
A recent commit in emacs-master breaks point focus
I updated my machine to Emacs master and found that I could no longer move the point across monitors (I'd have to use the mouse to click on the target monitor; the point icon would not move, even if I could type in the target buffer). The offending commit is between 07e6bbb9bc and 07e6bbb9bc.
I noticed that Po Lu did some work in this area (e.g., 5e7e85af02, "Stop passing CurrentTime to SetInputFocus"). I quickly tried to bisect, but didn't have time to find the problematic commit. If this is up to upstream to fix, please let me know and I will report it.
Gabriele Bozzola @.***> writes:
Yes, it works.
Thanks, we'll see if it makes it into EXWM then.
Manuel Giraud
Actually, the fix is not perfect. Sometimes (I still have to find out when exactly), the focus moves, but the icon for the point does not show up. I can interact as it was there, but I do not see it.
Will report later if I find the specific conditions that trigger this behavior.
Gabriele Bozzola @.***> writes:
Actually, the fix is not perfect. Sometimes (I still have to find out when exactly), the focus moves, but the icon for the point does not show up. I can interact as it was there, but I do not see it.
Will report later if I find the specific conditions that trigger this behavior.
Yes, that would be very helpful. I cannot see this but my usage of EXWM is very simple (just one monitor and almost no usage of workspaces).
Manuel Giraud
Yusef Aslam @.***> writes:
I've been trying out your PR and for me, it is fixed in
find-filewhen in X windows (focus is moved to the minibuffer), but not something likeconsult-bufferwhich I use to switch buffers using a menu in the minibuffer, where it stays hollow when an X window is selected.
Ok, I'm not a consult user myself but I've tested it and can reproduce what you say. So far, I do not understand what is the difference between a focus in the minibuffer via switch-to-buffer vs. via consult-buffer.
Manuel Giraud
In my case, it is always when moving the point to a different monitor. If I click with my mouse on the monitor where I have moved the point, the point materializes. But, this "invisible point" does not always happen, and I still haven't figured out how to trigger it.
Yusef Aslam @.***> writes: I've been trying out your PR and for me, it is fixed in
find-filewhen in X windows (focus is moved to the minibuffer), but not something likeconsult-bufferwhich I use to switch buffers using a menu in the minibuffer, where it stays hollow when an X window is selected. Ok, I'm not a consult user myself but I've tested it and can reproduce what you say. So far, I do not understand what is the difference between a focus in the minibuffer via switch-to-buffer vs. via consult-buffer. -- Manuel Giraud
Both the built-in switch-to-buffer and the other alternative consult-buffer have the same behavior for me, so it's probably the same problem whatever it is.
@Sbozzolo, do you use focus-follows-mouse (mouse-autoselect-window)?
@yusi1, @mgi: I can't reproduce. These are the steps I performed, with latest #890:
- Open XTerm (focus in XTerm X-Window)
- C-x C-f (focus moves to minibuffer)
- C-g (focus moves back to XTerm)
- C-x C-b (focus moves to minibuffer)
medranocalvo @.***> writes:
@Sbozzolo, do you use focus-follows-mouse (
mouse-autoselect-window)?@yusi1, @mgi: I can't reproduce. These are the steps I performed, with latest #890:
Yes, those steps also works for me (with second version of #890 didn't test the last). What was not working was with M-x consult-buffer. So as you said there are still issues but this patch is a first step.
Manuel Giraud
mouse-autoselect-window is set to nil.
Another piece of information I can provide is that this problem arises only (but not always) moving from a X app to a normal buffer on a different monitor.
I am the one who submit the bug https://debbugs.gnu.org/cgi/bugreport.cgi?bug=58245.
Po suggested me to add this line to my config, and everything is good afterwards.
(setq x-no-window-manager t)
Maybe you can all look into the complete thread of the bug, I actually encountered everything you all have mentioned above.
I am having the same issue and setting x-no-window-manager non-nil has made it better, thank you, but it is still not 100% fixed. I have noticed that for me the issue occured when I updated libX11 from 1.8.1 to 1.8.3.
I have built one emacs with libX11 1.8.1 and one with 1.8.3 and even though I am still not able to reproduce it certainly, I am confident in saying that somewhere between those two versions the issue is showing up.
[ANNOUNCE] libX11 1.8.2 https://www.spinics.net/lists/xorg/msg60726.html [ANNOUNCE] libX11 1.8.3 https://www.spinics.net/lists/xorg/msg60791.html https://gitlab.freedesktop.org/xorg/lib/libx11#release-183 https://gitlab.freedesktop.org/xorg/lib/libx11/-/compare/libX11-1.8.1...libX11-1.8.2 https://gitlab.freedesktop.org/xorg/lib/libx11/-/compare/libX11-1.8.2...libX11-1.8.3
I have just switched to libX11 1.8.4 and that has resolved the issue for me, as far as I can tell. That version includes this commit https://gitlab.freedesktop.org/xorg/lib/libx11/-/commit/eb1c272ab5230d548077b9f59aca4b3457c3a8f8 which seems to be fixing the issue.
I have also found this issue https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/176 which specifically talks about lost key sequences in emacs arising in 1.8.3.
