From: Len Trigg <lenbok@gmail.com>
Date: Sun, 29 Dec 2024 08:55:51 +1300
Cc: gerd.moellmann@gmail.com, 75056@debbugs.gnu.org

On Sat, 28 Dec 2024 at 20:52, Eli Zaretskii <eliz@gnu.org> wrote:

 Could you please extend your recipe so it starts from "emacs -nw -Q"?
 See, I don't have posframe or elpaca installed and don't use them, and
 don't want to install them just to reproduce and debug this problem.

Unless there's something I'm missing, the init file and startup command I provided did the installation of those
files for you into a temporary directory, so I thought that was the easiest self-contained path to reproducing.
Let me assume you've run it once that way initially in order to fetch the packages (otherwise you can
manually download the files if you want and adjust the paths in the below command line, but be aware that
you need new enough versions of posframe that understands tty child frame). Then to get a "emacs -nw -Q"
initialization you can use the attached test.el to do:

emacs -nw -Q --init-directory=~/emacs-test -l ~/emacs-test/elpaca/repos/vertico/vertico.el -l ~
/emacs-test/elpaca/repos/vertico/extensions/vertico-multiform.el -l ~
/emacs-test/elpaca/repos/posframe/posframe.el -l ~
/emacs-test/elpaca/repos/vertico-posframe/vertico-posframe.el  test.el

Then manually "eval" the remaining commands in test.el
(in another terminal) emacsclient -nw
Then invoke the child frame pop up: (C-x b and C-n to select *Messages* and RET). Now we're no longer in
a minibuffer.
Switch back to the original emacs terminal
Invoke the child frame pop up: (C-x b and C-n to select *Messages* and RET). Now we're no longer in a
minibuffer.
Swap to the emacsclient terminal, and note that the client is "hung".
 
I think this gives a specific enough recipe to minimally reproduce.

(vertico-mode)

(push '(tty-non-selected-cursor . t) vertico-posframe-parameters)
(push '(undecorated . nil) vertico-posframe-parameters)
(vertico-posframe-mode)

(server-start)

I tried this now, but I don't think I see the problem you describe.

I donwloaded vertico, posframe, and vertico-posframe packages from GNU
ELPA -- are the versions available there new enough to reproduce the
problem?  If not, where should I download these packages from?

Anyway, I can only observe a "hung" client if I forcibly switch from
an active minibuffer.  That is, after "C-x b" I don't select a buffer,
I simply type "C-x o" to switch out of the mini-window.  Then only the
client where I switched out of the mini-window can accept keyboard
input, the other one is "hung".

However, I can see the same situation even without these two packages:
if I start emacsclient, type "C-x b" there, and then "C-x o" to switch
away from the mini-window, Emacs on the other frame will stop responding
to keyboard input.  This is expected: when Emacs has an active
minibuffer on some display, Emacs temporarily switches to the
"single-keyboard mode".

But I suspect this is not what you see, so I wonder what did I not do
to reproduce the problem you see.