GNU bug report logs - #34179
27.0.50; message hangs when buffer with process visible

Previous Next

Full log

Message #86 received at 34179 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: michael_heerdegen <at> web.de, 34179 <at> debbugs.gnu.org
Subject: Re: bug#34179: 27.0.50; message hangs when buffer with process visible
Date: Fri, 25 Jan 2019 15:32:34 +0200

> Date: Fri, 25 Jan 2019 11:36:24 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: michael_heerdegen <at> web.de, 34179 <at> debbugs.gnu.org
> 
>  >> 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?

You are right, but window-font-width called by
window-max-chars-per-line also calls select-window.

Btw, I don't think replacing with-selected-window with
with-current-buffer will necessarily yield the same results.  And we
cannot in general forbid calls to with-selected-window in hooks called
from run_window_change_functions anyway, can we?

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

OK, but does that change anything?  Why is having a separate frame a
problem?

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

Not sure I understand what you mean.  The loop is in
redisplay_internal, not in window-configuration-change-hook.  How was
it easy to trigger that in the past?  And even if it was, shouldn't we
avoid such a loop?

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

I'm not sure, but let's talk again after I study that case, using the
recipe graciously provided by Andreas.

In any case, it is way too easy to do in functions called from
run_window_change_functions something that sets
windows_or_buffers_changed, so automatically retrying redisplay based
on that variable after run_window_change_functions returns is IMO
dangerous.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.