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

[martin rudalics]

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