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

Previous Next

Full log

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

From: martin rudalics <rudalics <at> gmx.at>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 34179 <at> debbugs.gnu.org
Subject: Re: 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

Previous Next

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