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

[Len Trigg <lenbok@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4006 bytes --]

Please excuse the top reply, I am traveling and my phone email client is limited. 

Eli, thanks for taking another look. AFAIK, posframe needs to be newer than what is released in ELPA. You can get the latest from <https://github.com/tumashu/posframe>

I also think that if you had the older version you would not have seen a tty-child-frame at all and so not have triggered the bug I see - In your test did C-x b bring up a tty child frame in the center of the window, or a regular minibuffer at the bottom of the screen? 

(You are correct that I did not switch away from the selector in my repro steps, I selected the buffer and exited normally with RET).

Cheers, 
Len.


On 5 January 2025 6:41:15 pm GMT+02:00, Eli Zaretskii <eliz@gnu.org> wrote:
>> 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.
>

[-- Attachment #2: Type: text/html, Size: 4544 bytes --]