bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: bug#75056: 31.0.50; tty-child-frames with server / multiple clients possible hangs
Date: Fri, 27 Dec 2024 14:28:59 +0200

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: lenbok@gmail.com,  75056@debbugs.gnu.org
> Date: Fri, 27 Dec 2024 10:04:29 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> >> Cc: lenbok@gmail.com,  75056@debbugs.gnu.org
> >> Date: Fri, 27 Dec 2024 09:46:48 +0100
> >> 
> >> Eli Zaretskii <eliz@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?
> 
> We're switching frames while being in the minibuffer in the other frame.
> 
> > I guess I'd love to see a C backtrace from that situation.
> 
> Too difficult for me. Emacs is not frozen in the sense that it is
> completely stuck somewhere. For example, C-x C-c apparently always
> works. C-g seems to work sometimes too, sometimes not. It's more like
> the keyboard input doesn't land where it is supposed to. Or something
> like that.

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?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]