GNU bug report logs - #71343
30.0.50; TTY frame doesn't automatically redisplay itself after having closed another frame

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Daniel Clemente <n142857 <at> gmail.com>
Cc: eggert <at> cs.ucla.edu, 71343 <at> debbugs.gnu.org
Subject: Re: bug#71343: 30.0.50; TTY frame doesn't automatically redisplay
 itself after having closed another frame
Date: Thu, 06 Jun 2024 16:44:00 +0300

> From: Daniel Clemente <n142857 <at> gmail.com>
> Date: Thu, 6 Jun 2024 13:24:59 +0000
> Cc: Paul Eggert <eggert <at> cs.ucla.edu>, 71343 <at> debbugs.gnu.org
> 
> Random ideas, without knowing much about terminals.
> - Can't an X terminal detect „I've been given X focus“ and pass this
> signal to the program running inside it?

You assume that it will be a terminal belonging to Emacs that will get
focus?  That is not given.

> - What if, when closing a TTY frame in emacsclient, all other frames
> are redisplayed

Why?

> - What if, when resizing the frame (something which Emacs detects),
> Emacs knows/detects that a frame was closed, and decides not to delay
> the redisplay?

Redisplay of which frame?  Emacs only redisplays a frame if some
change in buffer text justifies that.

> It's ok if it can't be fixed. I'm surprised that others didn't have
> this issue; but maybe not many are running TTY emacs (no X) inside an
> X window.

It is a rare and not very interesting situation: users aren't expected
to kill terminals, they are expected to "C-x #" to close Emacs
displays.

> I'm concerned about preventing cases in which the lack of redisplay
> can cause larger problems like mangled text.

Lack of redisplay cannot possibly produce garbled text because only
displaying something can do that.

Previous Next

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