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

[martin rudalics <rudalics@gmx.at>]

 >> 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.

But ‘with-current-buffer’ does not change a window's buffer.  Or what
am I missing?

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

The one from Michael's scenarios.  As in

   I can provoke the hang in emacs -Q by just doing M-x shell, C-x 5 2,
   and M-: (message "A\nB").

I can't get the hang with a single frame.  Can you?

 >> 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.

It's an infloop triggered in ‘window-configuration-change-hook’ and it
was always easy to trigger an infloop there.  Obviously, resizing the
minibuffer window did not trigger `window-configuration-change-hook'
at all before my change.

 > 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?

Bug#34138 is one example why redisplay should be triggered from within
a function on 'window-configuration-change-hook'.

martin