GNU bug report logs - #75056
31.0.50; tty-child-frames with server / multiple clients possible hangs

Previous Next

Full log

Message #425 received at 75056 <at> debbugs.gnu.org (full text, mbox):

From: Len Trigg <lenbok <at> gmail.com>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: Martin Rudalics <rudalics <at> gmx.at>, Eli Zaretskii <eliz <at> gnu.org>,
 75056 <at> debbugs.gnu.org
Subject: Re: bug#75056: 31.0.50; tty-child-frames with server / multiple
 clients possible hangs
Date: Wed, 26 Feb 2025 15:29:21 +1300

[Message part 1 (text/plain, inline)]

I thought I would check in and see if there was any changed behaviour with
respect to this bug, and things seem to be worse if anything.

First up, even just with a single tty emacs (i.e. no emacsclient), the
minibuffer behaviour has changed, so that now it seems the minibuffer
appears in both the tty child frame as well as the main tty frame. Steps to
reproduce (again, using my test init.el from OP):

emacs -nw --init-directory=~/emacs-test
M-x emacs-version RET
(Note that when typing emacs-version, there are two visible minibuffers).

Secondly, the two tty behaviour seems screwy, in that the first time a
child frame is invoked on the second client, it doesn't get
populated/drawn. Steps:

emacs -nw --init-directory=~/emacs-test
Switch to another terminal, side by side so you can see and switch between
both easily
emacsclient -nw
M-x emacs-version RET
(runs fine, other than the two-minibuffer issue mentioned above)
Switch focus back to the first terminal
M-x emacs-version
(note the child frame appears with just the outside border drawn, as shown
below)

[image: image.png]

Third, in a continuation of the two tty scenario, keyboard input (e.g.
moving point) in one client instead takes effect in the other client! Steps:

emacs -nw --init-directory=~/emacs-test
Switch to another terminal, side by side so you can see and switch between
both easily
emacsclient -nw
M-x emacs-version RET
(runs fine, other than the two-minibuffer issue mentioned above)
Switch focus back to the first terminal
M-x emacs-version RET
(as above, the child frame isn't drawn, but the command itself runs)
Switch focus back to the second client
C-n C-f C-f  (etc)
Note that the cursor is moving within the first client. Similarly, M-x
opens a tty child frame in the first client even though keyboard input is
coming from the second client.




On Sun, 16 Feb 2025 at 18:26, Gerd Möllmann <gerd.moellmann <at> gmail.com>
wrote:

>
> On 15. Feb 2025, at 19:20, martin rudalics <rudalics <at> gmx.at> wrote:
>
> > Works perfectly, thanks!
>
> There's a problem with moving nested child frames out of their child
> parents.  Load the attached tty-child-frames.el do first M-l and then
> C-M-l.  You should see a grey child frame embedded in an orange child
> frame.  Now do
>
> (set-frame-parameter tty-3 'left (- 30))
>
>
> Yep, I can reproduce it.
>
> Could be a problem with copying glyphs from the child to the root's
> desired matrix because the crash is from invalid glyph contents. When I
> reproduced it, the glyph in question was completely zeroed, for example.
>
> I've made bug#76321 for this. Can take me a bit to fix, I'm afraid.
>

[Message part 2 (text/html, inline)]

[image.png (image/png, inline)]

Previous Next

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