[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: martin rudalics
Subject: bug#34179: 27.0.50; message hangs when buffer with process visible
Date: Fri, 25 Jan 2019 10:44:54 +0100

>> Here's the Lisp backtrace:
>>    "select-window" (0x82a508)
>>    "window-max-chars-per-line" (0x82aae0)
>>    "window-adjust-process-window-size" (0x82b0a0)
>>    "window-adjust-process-window-size-smallest" (0x82b618)
>>    "window--adjust-process-windows" (0x82bbc0)
>>    "redisplay_internal (C function)" (0x0)
>>    "message" (0x82cdb0)
>>    "progn" (0x82cff8)
>>    "if" (0x82d198)
>>    "let*" (0x82d3c8)
>>    "catch" (0x82d608)
>>    "fracy-display-frame-list" (0x82d7c0)
>>    "if" (0x82dac8)
>>    "fracy-flash-window" (0x82dc80)
>>    "let" (0x82e018)
>>    "ad-Advice-handle-switch-frame" (0x82e4a0)
>>    "apply" (0x82e498)
>>    "handle-switch-frame" (0x82ebe0)
>>    "funcall-interactively" (0x82ebd8)
>>    "call-interactively" (0x82f030)
>>    "command-execute" (0x82f628)
>> The C portion of the backtrace below selec t-window is this:
>>    #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.  The problem is with having that separate
frame that gets its echo area resized.  I'm not sure what causes it
but I suppose it's 'window-configuration-change-hook' itself that
selects that frame for running the hook.

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


Attachment: window--adjust-process-windows.diff
Description: Text document

reply via email to

[Prev in Thread] Current Thread [Next in Thread]