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: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Len Trigg <lenbok <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 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 05:53:22 +0100

Len Trigg <lenbok <at> gmail.com> writes:

> On Sun, 26 Jan 2025 at 09:08, Gerd Möllmann <gerd.moellmann <at> gmail.com> wrote:
>
>  > I could see that prior to tty child frames that was necessarily true,
>  > but now we have tty child frames shouldn't that documentation be
>  > updated? (I'm assuming at the code level it's no longer true since
>  > posframe hides it's frames by simply making them invisible).
>
>  Yes, that's right, The visibility thing on ttys is now more like on
>  GUIs. We have to change the documentation.
>
> 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. At that point, I switch to F2.

What would a user then expect? I can't really answer that question
because it's not a use-case I'm familiar with. Maybe the minibuffer
should somehow be "migrated" from F1 to F2? Including the completions
buffer? Or should Emacs display an error when we select F2 and maybe try
to switch back to F1? No idea. If the minibuffer is migrated to F2, what
would I expect to happen on F1? Closing the completions window, leaving
the minibuffer?

Then see admin/notes/multi-tty. What does it say about things? Or maybe
Elisp Info.

Then look at what really happens, and compare.

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?

I think only if that all works as expected, including Vertico and others
which play with the minibuffer, only then I would bring Posframe into
play.

Previous Next

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