bug#71343: 30.0.50; TTY frame doesn't automatically redisplay itself after having closed another frame

[Daniel Clemente]

Note that I just posted a simpler way to understand this bug. No need
to read the complex recipe with left/right columns.

> I'm not sure this is a bug.  Emacs switches to reading input from a
> different terminal/keyboard when there's actually some input from that
> terminal's keyboard.  In the situation you described, the terminal
> whose keyboard was active was killed.  I'm guessing we get SIGHUP in
> this case, so we could do something about it, but what exactly should
> we do?  Since no other keyboard provided any input, to which keyboard
> to switch, and why?

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?
- What if, when closing a TTY frame in emacsclient, all other frames
are redisplayed
- 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?

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.

I'm concerned about preventing cases in which the lack of redisplay
can cause larger problems like mangled text. I just posted a comment
at 71289 about a redisplay bug I saw, but I don't know whether it's
related to closing or to resizing frames.
Hopefully this issue (71343) can't cause mangled text in any situation.