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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: lenbok <at> gmail.com, 75056 <at> debbugs.gnu.org
Subject: bug#75056: 31.0.50; tty-child-frames with server / multiple clients possible hangs
Date: Fri, 27 Dec 2024 10:54:19 +0200

> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: lenbok <at> gmail.com,  75056 <at> debbugs.gnu.org
> Date: Fri, 27 Dec 2024 09:46:48 +0100
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Can you explain how the above limitation causes the problem reported
> > in this bug?  That is, how do child frames trigger the bug?  Because
> > "normal" frames don't, AFAIU, right?  That is, one could have two or
> > more client TTY frames on several displays in the same Emacs session,
> > without having any of them stop being responsive, right?  Also, what
> > is the role of vertico-posframe in this scenario?
> 
> The hint I see is here
> 
> >> 	  If your multi-tty Emacs session seems to be frozen, you
> >> 	  probably have a recursive editing session or a pending
> >> 	  minibuffer prompt (which is a kind of recursive editing) on
> >> 	  another display.
> 
> Emacs in our case is kind of frozen, and Vertico is a minibuffer
> interaction, where Posframe simply displays the minibuffer differently,
> in a child frame.

Yes, but where is that recursive editing in this scenario?

I guess I'd love to see a C backtrace from that situation.

Previous Next

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