GNU bug report logs - #75056
31.0.50; tty-child-frames with server / multiple clients possible hangs

Previous Next

Full log

Message #62 received at 75056 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Len Trigg <lenbok <at> gmail.com>
Cc: gerd.moellmann <at> gmail.com, 75056 <at> debbugs.gnu.org
Subject: Re: bug#75056: 31.0.50; tty-child-frames with server / multiple
 clients possible hangs
Date: Sun, 05 Jan 2025 18:41:15 +0200

> From: Len Trigg <lenbok <at> gmail.com>
> Date: Sun, 29 Dec 2024 08:55:51 +1300
> Cc: gerd.moellmann <at> gmail.com, 75056 <at> debbugs.gnu.org
> 
> On Sat, 28 Dec 2024 at 20:52, Eli Zaretskii <eliz <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.