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

From: martin rudalics <[email-masked]>
Date: Wed, 29 Jan 2025 10:05:51 +0100

> Taking a closer look at tty_set_cursor, using the selected frame here
 > doesn't make sense to me. I don't see a good reason why the selected
 > frame has to have anything to do with where to place the cursor in an
 > updated frame. That looks more like a left-over from times before
 > multi-tty.

But it seemed to work on the release branch.  Anyway, with your patches
I don't see the assertion violation any more so you should check them
in.  Maybe you should also adapt the comment

    SET_CURSOR_P false means do not set cursor at point in selected window.  */

at the beginning of write_matrix.

 > Could you please try the attached, Martin? The first one is what I think
 > it the fix. The second one is a cleanup that leads to more checks
 > without having GLYPH_DEBUG. If this also work for you, I'll put that in
 > master.

If my build with GLYPH_DEBUG works, wouldn't it also work without?

 > (I see a "flicker" of the tty frame after the make-frame. That is also
 > the case in Emacs 30.)

Absolutely no flicker here but the "icon" of the new frame on my
desktop's "tool bar" is blinking and the new frame is not "active" (I
have no idea whatever the equivalents of these on your ns desktop are).
After I click into the new frame the blinking stops.  This is distinct
from what happens with 'make-frame' on a GUI frame here, where the new
frame gets input focus and is selected.  But it looks to me like a good
solution for the case at hand here.

martin