Subject: Re: bug#16674: 24.3.50; crash: redisplay_internal, update_frame, using client-daemon in tmux

From: Eli Zaretskii <[email-masked]>
Date: Sun, 09 Feb 2014 19:27:08 +0200

> From: Mark Oteiza <[email-masked]>
> Date: Sun, 09 Feb 2014 02:39:09 -0500
> 
> Eli Zaretskii <[email-masked]> writes:
> 
> >> From: Mark Oteiza <[email-masked]>
> >> Date: Fri, 07 Feb 2014 11:06:40 -0500
> >> 
> >> |A|B|
> >> 
> >> Now, "B" has focus. I exit from this client into the shell, and exit the
> >> shell, killing the tmux pane.  At this point, the pane "A" occupies is
> >> the sole pane, but "A" is still only occupying half the window!
> >> 
> >> |A  |
> >> 
> >> I can make and destroy tmux panes and constrict the client
> >> "display". The frame won't update until I enter the pane "A" occupies
> >> *and* interact with the client.
> >
> > Sounds like Emacs is not being told about these changes.  Do they send
> > the SIGWINCH signal?  If not, how is Emacs supposed to know about
> > them?
> 
> Ok, in this example, no SIGWINCH is sent when "B" is closed and the pane
> it occupied (stracing client "A").
> 
> It seems like when the focused client is killed, no other client gets
> "updated" until some input happens; either mouse click with
> xterm-input-mode or keyboard input.

Not sure what Emacs can do under these conditions.  However, it worked
before this change:

> >> This does not happen in 24.3, so this is a regression I imagine I can
> >> bisect if need be.
> >
> > Please do, and thanks.
> 
> I found 0cd28af (references Bug#15025).

Dmitry, this is bzr revision 113891.  Perhaps the new code in
delete_frame should include a few more tests from candidate_frame?
(That's just a wild guess, though: I don't really understand what does
tmux do to Emacs -- are we selecting a frame that is no longer
displayed or something?)