Focusing minibuffer from X11 window causes "Buffer is read only" error

[lrustand]

How to reproduce:

1. Open an X11 terminal emulator, for example xterm
2. Run emacsclient -e '(completing-read "Prompt: " (list "1" "2" "3"))'
3. Select something from the list
4. Try to type something into the X11 terminal.

The first keypress after the minibuffer is closed seems to go to the underlying emacs buffer of the EXWM window instead of to the X11 window inside it, causing a "Buffer is read only" error. Subsequent keypresses after the first one is sent correctly to the X11 window.

EDIT: Note that this only happens if the minibuffer is opened by other means than through a keybind. If I open the minibuffer by pressing M-x, 'C-x b' or similar, then the focus is returned correctly to the X11 window.

[Stebalien]

• What EXWM and Emacs version?
• What completion system? Can you reproduce with emacsclient -e '(read-string "prompt: ")'?

I remember reporting this ages ago (ch11ng/exwm#253), but I haven't seen this issue in a while.

[lrustand]

What EXWM and Emacs version?

• GNU Emacs 30.0.91 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.41, cairo version 1.18.0)
• EXWM 0.32

What completion system?

I'm normally using Vertico, but have tested with Ivy also. Both produce the same behaviour.

Can you reproduce with emacsclient -e '(read-string "prompt: ")'?

I can partly reproduce with read-string by aborting it without accepting any input, which will produce the described behaviour. If I accept an entered string it seems to work correctly.

I'm also not the only one experiencing this. The issue was first reported to me here: lrustand/qutebrowser.el#7.

EDIT: But please, try for yourself, I'm almost certain you will be able to reproduce it.

[Stebalien]

Ooh. Interesting. I was trying it with alacritty and couldn't reproduce, but I can reproduce with xterm.

[lrustand]

Okay, that is strange. I have the same issue no matter what is the "source" of the command. As you can see in the issue I linked, and in the following discussion in lrustand/qutebrowser.el#9, it also happens when emacsclient is invoked from qutebrowser, and it can even be reproduced without the use of emacsclient (using a unix socket for direct communication instead).

I tested with some more terminal emulators (konsole, urxvt, kitty, terminator) now just in case, but every single one of them show the exact same behaviour. I don't think this is dependent on which one you use.

I even tested running the emacsclient from another tty while an X11 window was the active buffer in EXWM, and this reproduces as well.

[Stebalien]

🤦‍♂️ you're right, this reproduces everywhere. I'm sorry about that.

I have a snippet in my personal config that makes EXWM buffers read/write re-plays all text entered into EXWM buffers into the correct EXWM window (to get let regular emacs commands write into X windows). Unfortunately, that was masking this issue.

[Stebalien]

Ok, with vertico at least, the issue is:

1. On exiting the minibuffer, the pre-command hook runs for vertico-exit but not the post-command hook.
2. Then we try to enter a character and fail because exwm-input--during-command is non-nil.

I think this is an Emacs issue (real-this-command) also doesn't get reset.

However, I'm not even sure if the exwm-input--during-command mechanism is necessary anymore after 8ea607b. When I remove it, everything still seems to work (although that'll require more testing).

[Stebalien]

Note: you can "fix" it for completing-read by adding vertico-exit to exwm-input-pre-post-command-blacklist. But I'm going to try removing all this code because:

1. I don't think it's necessary anymore.
2. emacsclient -e '(yes-or-no-p "foo")' is broken as well.

[lrustand]

I've tested both your quick fix and your PR, and both seem to mostly solve the problem. It now works flawlessly when completing-read or other commands finish succesfully. It still happens if the completing-read is aborted without accepting an entry, but this might be a separate issue.

[Stebalien]

Hm. You're right, it still happens in that case. I also see the emacsclient command hang until pressing a key so something interesting is happening there.

[Stebalien]

Ah, well, I found the issue. Aborting an emacsclient command ends up calling (sit-for 2) (sleep for 2 seconds). This internally calls read-event which we advise with exwm-input--call-with-passthrough. Usually, when read-event is called, it's because some command wants to get a user-input event. Unfortunately, in this case, sit-for is just using it as a way to abort early. After reading the event it'll push it back into the unread-command-events queue, which will then be processed by Emacs instead of by EXWM.

I'm not sure how best to deal with this. I think the answer is to advise sit-for somehow, but I'm hoping there's a better way.

[minad]

The issue occurs also with emacsclient -e '(sit-for 3)'.

[lrustand]

But this secondary issue seems to only happen with emacsclient. Other ways of remotely triggering completing-read has been fully fixed by your workaround. For example, sending the command through a unix socket like this works fine even if the command is aborted:

(make-network-process :name "eval-listener"
                        :family 'local
                        :service "/tmp/emacs-eval"
                        :server t
                        :filter (lambda (proc string)
                                  (eval (read string)))
                        :coding 'utf-8)

And then in xterm:

echo "(completing-read \"Prompt:\" '(\"1\" \"2\" \"3\"))" | socat - UNIX-CONNECT:/tmp/emacs-eval

(This did previously reproduce the original issue, but has now been fully fixed)