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 15:02:37 +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 13:47:09 +0100
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Then why is this a bug?
> >
> > When a frame is in a minibuffer, it means Emacs asks the user about
> > something, and in that situation, the user must respond to the prompt,
> > or exit the minibuffer in some other way.  That's normal in my book.
> > What am I missing?
> 
> Emacs doesn't say anything.

It does: on the frame where you are in the minibuffer.

> The user is just typing into the void, and it's not easy get out of
> this state again, except C-x C-c. That's not normal.

My point is that this happens in many other, "simpler" situations.
AFAIK, it isn't limited to TTY frames, either.  So if that's the only
thing that happens here, i.e. some other frame is parked at the
minibuffer prompt, there's nothing new here that we didn't have before
child frames became supported on TTY displays.  Changing that would
need to have per-frame input queues in Emacs, AFAIU, and some way of
multiplexing between them.

But I'm not yet sure this is what we see in this case, which is why I
asked for a C backtrace.  Producing it should be easy: just reproduce
the problem, then attach a debugger and produce the backtrace.

Previous Next

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