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 #17 received at 71343 <at> debbugs.gnu.org (full text, mbox):
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.
This bug report was last modified 1 year and 54 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.