A recent commit in emacs-master breaks point focus

[Sbozzolo]

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.

[mgi]

Hi,

I'd be happy to hear if #890 fixes your issue.

Best regards,

[Sbozzolo]

Yes, it works.

[mgi]

Gabriele Bozzola ***@***.***> writes:

Yes, it works.

Thanks, we'll see if it makes it into EXWM then. -- Manuel Giraud

[Sbozzolo]

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.

[mgi]

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

[mgi]

Yusef Aslam ***@***.***> writes:

I've been trying out your PR and for me, it is fixed in `find-file` when in X windows (focus is moved to the minibuffer), but not something like `consult-buffer` which 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

[Sbozzolo]

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.

[yusi1]

Yusef Aslam @.***> writes:
I've been trying out your PR and for me, it is fixed in find-file when in X windows (focus is moved to the minibuffer), but not something like consult-buffer which 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.

[medranocalvo]

@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:

1. Open XTerm (focus in XTerm X-Window)
2. C-x C-f (focus moves to minibuffer)
3. C-g (focus moves back to XTerm)
4. C-x C-b (focus moves to minibuffer)

[mgi]

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 <kbd>M-x consult-buffer</kbd>. So as you said there are still issues but this patch is a first step. -- Manuel Giraud

[Sbozzolo]

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.

[drshapeless]

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.

[nagy]

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

[nagy]

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.

[pmiddend]

For me (setq x-no-window-manager t) fixes the issue.