GNU bug report logs -
#71343
30.0.50; TTY frame doesn't automatically redisplay itself after having closed another frame
Previous Next
Full log
View this message in rfc822 format
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 362 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.