bug#34179: 27.0.50; message hangs when buffer with process visible

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 25 Jan 2019 10:44:54 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: 34179@debbugs.gnu.org
> 
>  >>    #0  redisplay_other_windows () at xdisp.c:597
>  >>    #1  0x010aa09e in select_window (window=XIL(0xa000000006919aa0),
>  >>        norecord=XIL(0x3d36a14), inhibit_point_swap=false) at window.c:540
>  >>    #2  0x010aa62a in Fselect_window (window=XIL(0xa000000006919aa0),
>  >>        norecord=XIL(0x3d36a14)) at window.c:628
>  >
>  > To clarify: these backtraces show where windows_or_buffers_changed is
>  > being set to the value of 2, which causes us to retry redisplay.  It
>  > is a direct consequence of the fact that window-max-chars-per-line
>  > calls select-window.
> 
> If I replace the line
> 
>    (with-selected-window (window-normalize-window window t)
> 
> of 'window-max-chars-per-line' by the line
> 
>    (with-current-buffer (window-buffer window)
> 
> the problem persists.  So it is not the 'select-window' call per se
> that causes the trouble.

That's because both selecting a window and changing its buffer sets
windows_or_buffers_changed via redisplay_other_windows.

> The problem is with having that separate frame that gets its echo
> area resized.

What separate frame?

> Using 'window-size-change-functions' (patch attached) instead of
> 'window-configuration-change-hook' fixes the problem here.

That might be a good change anyway, but the more general problem of
having an easily triggered infloop in redisplay_internal remains, and
we should fix that, IMO.

Let me turn the table and ask: why do we need to retry redisplay when
some function called from run_window_change_functions does something
that requires redisplay?  Why not leave that to the next redisplay
cycle?