Subject: Re: bug#75056: 31.0.50; tty-child-frames with server / multiple clients possible hangs

From: Gerd Möllmann <[email-masked]>
Date: Sun, 26 Jan 2025 08:50:14 +0100

Eli Zaretskii <[email-masked]> writes:

>> 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.

Right, sorry, I forgot that I have consult-buffer on C-x b.

>> 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.

I would perhaps check how that switching to single-kboard is done. That
is, which C functions do that, what does do_switch_frame do and so on.
And why does the mini_frame in redisplay_internal end up invisible? Is
F1 invisible now, and if so why?

And then see if that all is what admin/notes/multi-tty says is intended,
if there are open issues, and so on.

Something like that, maybe.