bug-gnu-emacs
[Top][All Lists]
Advanced

[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: Sat, 26 Jan 2019 19:48:54 +0100

>    With emacs -Q do M-x shell, C-x 5 2, and M-: (message "A\nB").
>
> Here with emacs 25 this grows the minibuffer window and displays the
> two lines
>
> A
> B
>
> in it.  With emacs 26 it shortly resizes the minibuffer window and
> then displays "A\nB" in it.  With patched master it displays
>
> Eval: (message "A\nB")
>
> with the cursor at the beginning of the minibuffer.
>
> I have no idea yet what's causing these behaviors but so far the
> presence of an external procees or shell looks like a necessary
> prerequisite.  Ideas welcome.

Three ingredients are needed:

(1) redisplay_internal has this

  if ((!NILP (echo_area_buffer[0]) && !display_last_displayed_message_p)
      || (!NILP (echo_area_buffer[1]) && display_last_displayed_message_p)
      || (message_cleared_p
          && minibuf_level == 0
          /* If the mini-window is currently selected, this means the
             echo-area doesn't show through.  */
          && !MINI_WINDOW_P (XWINDOW (selected_window))))
    {
      echo_area_display (false);

      if (message_cleared_p)
        update_miniwindow_p = true;

and we run the window change functions after it.

(2) do_switch_frame has this

  if (!for_deletion && FRAME_HAS_MINIBUF_P (sf))
    resize_mini_window (XWINDOW (FRAME_MINIBUF_WINDOW (sf)), 1);

(3) 'window-max-chars-per-line' has this

  (with-selected-window (window-normalize-window window t)

Note that we want to display a two-line message on F1 and a function
on 'window-configuration-change-hook' runs 'window-max-chars-per-line'
on a frame F2.  Here this shifts five (why?) times the message from
the echo area of F1 to that of F2 simultaneously shrinking and growing
the two minibuffer windows.  At the very end the message apparently
gets lost because we do not execute (1) after the last switch from F2
to F1.  Running 'window-configuration-change-hook' before the
echo_area_display (false) fixes the problem but obviously misses any
height change induced by that call.

AFAICT there is no solution to this problem.  The best approximation
seems to maybe redisplay the echo area a second time after running the
window change functions.

martin





reply via email to

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