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: Sun, 26 Jan 2025 09:33:45 +0200

> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  75056 <at> debbugs.gnu.org
> Date: Sun, 26 Jan 2025 05:53:22 +0100
> 
> Len Trigg <lenbok <at> gmail.com> writes:
> 
> > OK, so would I be correct that our current understanding of this bug
> > is now best described as "something is setting previously invisible
> > tty child frames as visible when focus changes to an alternative tty
> > client"? (Possibly some part of the multi-tty code that still assumes
> > that all tty frames are always visible). This then causes the
> > non-focused client to display the tty child frame with minibuffer that
> > then blocks input from other clients due to the existing single-kboard
> > limitation.
> 
> "Understanding" is a bit much said, as far as I am concerned. If I
> wanted to debug this, which I don't :-), my start hypotheses would be
> that this has to do with the minibuffer, yes.
> 
> I would first try to find out what does multi-tty Emacs do when Posframe
> is not involved. Say we have two frames F1 and F2 on different ttys. On
> F1, I enter the minibuffer with C-x C-b for example, and open a
> completion window.

I guess you meant "C-x b TAB".  "C-x C-b" doesn't activate the
minibuffer.

> At that point, I switch to F2.
> 
> What would a user then expect?

What happens in this case is that F2 cannot be communicated with:
typing anything there gets no response, until we exit the minibuffer
on F1.  Then everything you typed on F2 gets processed.

> Find in the code what actually happens when switching from F1 to F2 and
> compare that with admin/notes/multi-tty has to say about that. Does that
> document say something about what we've seen the code doing? Open issues
> maybe? Or general considerations?

What the code does when Emacs enters a minibuffer is switch to a
"single-keyboard mode", whereby it only processes keyboard input from
the frame which entered the minibuffer.  This is because Emacs has
only one input queue.

Previous Next

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