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

Previous Next

Package: emacs;

Reported by: Michael Heerdegen <michael_heerdegen <at> web.de>

Date: Wed, 23 Jan 2019 15:11:02 UTC

Severity: normal

Found in version 27.0.50

Fixed in version 27.1

Done: Noam Postavsky <npostavs <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: michael_heerdegen <at> web.de, 34179 <at> debbugs.gnu.org
Subject: bug#34179: 27.0.50; message hangs when buffer with process visible
Date: Fri, 25 Jan 2019 11:36:24 +0100
>> 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





This bug report was last modified 6 years and 54 days ago.

Previous Next


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