GNU bug report logs - #21869
Redisplay: after echo area diminishes in size, Follow Mode windows aren't resynchronised.

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 21869 in the body.
You can then email your comments to 21869 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Alan Mackenzie <acm <at> muc.de>
To: bug-gnu-emacs <at> gnu.org
Subject: Redisplay: after echo area diminishes in size, Follow Mode windows
 aren't resynchronised.
Date: Mon, 9 Nov 2015 09:35:46 +0000

Hello, Emacs.

With a recent copy of the git master, in either X windows or a Linux tty,

emacs -Q

If necessary, make the window wide with the mouse.

C-x C-f src/xdisp.c       ; or any other non-small file.
C-x 3
M-x follow-mode

Note the content of the lines around the window division.

M-: (message "x\ny\nz") <CR>

The echo area expands, and the two Follow Mode windows get correctly
synchronised.  Again, note the content of the lines around the window
division.

C-f

The echo area shrinks back to its normal size.  Note the content of the
lines around the window division.  The two lines at the bottom of the
left hand window are also displayed at the top of the right hand window.
The windows have NOT been synchronised after the change in the echo area
size.  This is a bug.

#########################################################################

Tentative analysis:

Follow Mode puts a function on window-scroll-functions which should be
called any time a window changes size.  At the C-f above,
window-size-change-functions is not being invoked.

The one single place where window-size-change-functions is invoked is in
the function prepare_menu_bars in xdisp.c.

The one single place where prepare_menu_bars is called is fairly early on
in redisplay_internal, at L+137.  This is before the echo area is resized
at L+164.  Thus, the check on changed window sizes happens too early,
before the change in the echo area size.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

From: martin rudalics <rudalics <at> gmx.at>
To: Alan Mackenzie <acm <at> muc.de>, 21869 <at> debbugs.gnu.org, 
 Pip Cet <pipcet <at> gmail.com>
Subject: Re: bug#21869: Redisplay: after echo area diminishes in size, Follow
 Mode windows aren't resynchronised.
Date: Mon, 09 Nov 2015 11:04:16 +0100

> Follow Mode puts a function on window-scroll-functions which should be

I suppose you mean ‘window-size-change-functions’.

> called any time

Not really.

> a window changes size.  At the C-f above,
> window-size-change-functions is not being invoked.
>
> The one single place where window-size-change-functions is invoked is in
> the function prepare_menu_bars in xdisp.c.
>
> The one single place where prepare_menu_bars is called is fairly early on
> in redisplay_internal, at L+137.  This is before the echo area is resized
> at L+164.  Thus, the check on changed window sizes happens too early,
> before the change in the echo area size.

Probably bug#830 and bug#21333.

Pip are you still alive?  Have your papers arrived?

martin

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

From: Alan Mackenzie <acm <at> muc.de>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 21869 <at> debbugs.gnu.org, Pip Cet <pipcet <at> gmail.com>
Subject: Re: bug#21869: Redisplay: after echo area diminishes in size, Follow
 Mode windows aren't resynchronised.
Date: Mon, 9 Nov 2015 11:15:05 +0000

Hello, Martin.

On Mon, Nov 09, 2015 at 11:04:16AM +0100, martin rudalics wrote:
>  > Follow Mode puts a function on window-scroll-functions which should be

> I suppose you mean ‘window-size-change-functions’.

Yes, that was what I meant.  Sorry about the inaccuracy.

>  > called any time

> Not really.

>  > a window changes size.  At the C-f above,
>  > window-size-change-functions is not being invoked.

>  > The one single place where window-size-change-functions is invoked is in
>  > the function prepare_menu_bars in xdisp.c.

>  > The one single place where prepare_menu_bars is called is fairly early on
>  > in redisplay_internal, at L+137.  This is before the echo area is resized
>  > at L+164.  Thus, the check on changed window sizes happens too early,
>  > before the change in the echo area size.

> Probably bug#830 and bug#21333.

Yes, probably.  What this bug might add to the debate is that here, the
misalignment of the windows persists after the echo area returns to its
normal size.

It is not good that window-size-change-functions gets called when the
echo area expands, but not when it shrinks again.  This is unsymmetric.

> martin

-- 
Alan Mackenzie (Nuremberg, Germany).

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: acm <at> muc.de, 21869 <at> debbugs.gnu.org, pipcet <at> gmail.com
Subject: Re: bug#21869: Redisplay: after echo area diminishes in size,
 Follow Mode windows aren't resynchronised.
Date: Mon, 09 Nov 2015 18:10:35 +0200

> Date: Mon, 09 Nov 2015 11:04:16 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> 
> Pip are you still alive?  Have your papers arrived?

According to the FSF records, the papers did arrive.

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

From: Alan Mackenzie <acm <at> muc.de>
To: gnu-emacs-bug <at> moderators.isc.org
Subject: Re: bug#21869: Redisplay: after echo area diminishes in size,
 Follow Mode windows aren't resynchronised.
Date: Mon, 9 Nov 2015 18:18:33 +0000 (UTC)

Alan Mackenzie <acm <at> muc.de> wrote:
> With a recent copy of the git master, in either X windows or a Linux tty,

> emacs -Q

> If necessary, make the window wide with the mouse.

> C-x C-f src/xdisp.c       ; or any other non-small file.
> C-x 3
> M-x follow-mode

> Note the content of the lines around the window division.

> M-: (message "x\ny\nz") <CR>

> The echo area expands, and the two Follow Mode windows get correctly
> synchronised.  Again, note the content of the lines around the window
> division.

> C-f

> The echo area shrinks back to its normal size.  Note the content of the
> lines around the window division.  The two lines at the bottom of the
> left hand window are also displayed at the top of the right hand window.
> The windows have NOT been synchronised after the change in the echo area
> size.  This is a bug.

> #########################################################################

> Tentative analysis:

> Follow Mode puts a function on window-size-change-functions which should be
> called any time a window changes size.  At the C-f above,
> window-size-change-functions is not being invoked.

> The one single place where window-size-change-functions is invoked is in
> the function prepare_menu_bars in xdisp.c.

> The one single place where prepare_menu_bars is called is fairly early on
> in redisplay_internal, at L+137.  This is before the echo area is resized
> at L+164.  Thus, the check on changed window sizes happens too early,
> before the change in the echo area size.

I withdraw my complaint: the doc of w-s-c-functions says it is called
BEFORE REDISPLAY when a window size has changed.  It says nothing about
being called when the window sizes change DURING redisplay.

However, that leaves a gap: how is application software to be informed
that this change in window sizes has happened?  Perhaps changing the
hook's definition, such that it would be invoked both before redisplay
and during it would be a neat solution.  It seems that the chances of the
hook being invoked twice on a redisplay cycle would not be high.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

From: Alan Mackenzie <acm <at> muc.de>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 21869 <at> debbugs.gnu.org, Pip Cet <pipcet <at> gmail.com>
Subject: Re: bug#21869: [Patch] Redisplay: after echo area diminishes in
 size, Follow Mode windows aren't resynchronised.
Date: Mon, 9 Nov 2015 19:42:00 +0000

Hello again, Martin.

On Mon, Nov 09, 2015 at 11:04:16AM +0100, martin rudalics wrote:

>  > a window changes size.  At the C-f above,
>  > window-size-change-functions is not being invoked.

>  > The one single place where window-size-change-functions is invoked is in
>  > the function prepare_menu_bars in xdisp.c.

>  > The one single place where prepare_menu_bars is called is fairly early on
>  > in redisplay_internal, at L+137.  This is before the echo area is resized
>  > at L+164.  Thus, the check on changed window sizes happens too early,
>  > before the change in the echo area size.

> Probably bug#830 and bug#21333.

> Pip are you still alive?  Have your papers arrived?

Here's a proposed fix.  It seems to work.  Do you think there are any
problems with it?



diff --git a/src/xdisp.c b/src/xdisp.c
index bdf2d09..aacbb8a 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -11193,13 +11193,15 @@ echo_area_display (bool update_frame_p)
 {
   Lisp_Object mini_window;
   struct window *w;
+  Lisp_Object frame;
   struct frame *f;
   bool window_height_changed_p = false;
   struct frame *sf = SELECTED_FRAME ();
 
   mini_window = FRAME_MINIBUF_WINDOW (sf);
   w = XWINDOW (mini_window);
-  f = XFRAME (WINDOW_FRAME (w));
+  frame = WINDOW_FRAME (w);
+  f = XFRAME (frame);
 
   /* Don't display if frame is invisible or not yet initialized.  */
   if (!FRAME_VISIBLE_P (f) || !f->glyphs_initialized_p)
@@ -11222,6 +11224,19 @@ echo_area_display (bool update_frame_p)
       window_height_changed_p = display_echo_area (w);
       w->must_be_updated_p = true;
 
+      if (window_height_changed_p)
+	{
+	  Lisp_Object functions;
+
+	  functions = Vwindow_size_change_functions;
+	  while (CONSP (functions))
+	    {
+	      if (!EQ (XCAR (functions), Qt))
+		call1 (XCAR (functions), frame);
+	      functions = XCDR (functions);
+	    }
+	}
+
       /* Update the display, unless called from redisplay_internal.
 	 Also don't update the screen during redisplay itself.  The
 	 update will happen at the end of redisplay, and an update
@@ -31121,6 +31136,10 @@ the buffer when it becomes large.  */);
 
   DEFVAR_LISP ("window-size-change-functions", Vwindow_size_change_functions,
     doc: /* Functions called before redisplay, if window sizes have changed.
+The functions are also called during redisplay, if the minibuffer window (and
+hence other windows) change size.  This call happens before the other windows
+are redisplayed.
+
 The value should be a list of functions that take one argument.
 Just before redisplay, for each frame, if any of its windows have changed
 size since the last redisplay, or have been split or deleted,


> martin

-- 
Alan Mackenzie (Nuremberg, Germany).

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Mackenzie <acm <at> muc.de>
Cc: rudalics <at> gmx.at, 21869 <at> debbugs.gnu.org, pipcet <at> gmail.com
Subject: Re: bug#21869: [Patch] Redisplay: after echo area diminishes in size,
 Follow Mode windows aren't resynchronised.
Date: Mon, 09 Nov 2015 22:50:57 +0200

> Date: Mon, 9 Nov 2015 19:42:00 +0000
> From: Alan Mackenzie <acm <at> muc.de>
> Cc: 21869 <at> debbugs.gnu.org, Pip Cet <pipcet <at> gmail.com>
> 
> > Probably bug#830 and bug#21333.
> 
> > Pip are you still alive?  Have your papers arrived?
> 
> Here's a proposed fix.  It seems to work.  Do you think there are any
> problems with it?

We had a patch in bug #21333 which was discussed and tested at
length.  Please see if it works for your use case as well.  If not,
please tell why not.

Thanks.

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

From: Alan Mackenzie <acm <at> muc.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rudalics <at> gmx.at, 21869 <at> debbugs.gnu.org, pipcet <at> gmail.com
Subject: Re: bug#21869: [Patch] Redisplay: after echo area diminishes in
 size,	Follow Mode windows aren't resynchronised.
Date: Tue, 10 Nov 2015 13:49:58 +0000

Hello, Eli.

On Mon, Nov 09, 2015 at 10:50:57PM +0200, Eli Zaretskii wrote:
> > Date: Mon, 9 Nov 2015 19:42:00 +0000
> > From: Alan Mackenzie <acm <at> muc.de>
> > Cc: 21869 <at> debbugs.gnu.org, Pip Cet <pipcet <at> gmail.com>

> > > Probably bug#830 and bug#21333.

> > > Pip are you still alive?  Have your papers arrived?

> > Here's a proposed fix.  It seems to work.  Do you think there are any
> > problems with it?

> We had a patch in bug #21333 which was discussed and tested at
> length.  Please see if it works for your use case as well.  If not,
> please tell why not.

I had to struggle with the posts in that bug archive.  I'm not entirely
certain whether there was more than one patch in the thread, and if so
whether I tried out the one you mean.  For clarity, the patch I tried
was the one from Pip Cet's opening post in the thread, this one:

#########################################################################
From 243be700591979554e61bbdff0f00f30cc386f7b Mon Sep 17 00:00:00 2001
From: Philip <pipcet <at> gmail.com>
Date: Sun, 23 Aug 2015 21:46:42 +0000
Subject: [PATCH] Call `window-size-change-functions' after mini-window size
 changes.

	* window.c (resize_frame_windows): Set
	FRAME_WINDOW_SIZES_CHANGED flag.  (grow_mini_window):
	Likewise.  (shrink_mini_window): Likewise.
---
 src/window.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/window.c b/src/window.c
index 863a792..68bc9e5 100644
--- a/src/window.c
+++ b/src/window.c
@@ -4094,6 +4094,7 @@ resize_frame_windows (struct frame *f, int size, bool horflag, bool pixelwise)
     }
 
   fset_redisplay (f);
+  FRAME_WINDOW_SIZES_CHANGED (f) = true;
 }
 
 
@@ -4531,6 +4532,7 @@ grow_mini_window (struct window *w, int delta, bool pixelwise)
 	  /* Enforce full redisplay of the frame.  */
 	  /* FIXME: Shouldn't window--resize-root-window-vertically do it?  */
 	  fset_redisplay (f);
+	  FRAME_WINDOW_SIZES_CHANGED (f) = true;
 	  adjust_frame_glyphs (f);
 	  unblock_input ();
 	}
@@ -4570,6 +4572,7 @@ shrink_mini_window (struct window *w, bool pixelwise)
 	  /* Enforce full redisplay of the frame.  */
 	  /* FIXME: Shouldn't window--resize-root-window-vertically do it?  */
 	  fset_redisplay (f);
+	  FRAME_WINDOW_SIZES_CHANGED (f) = true;
 	  adjust_frame_glyphs (f);
 	  unblock_input ();
 	}
#########################################################################

This patch didn't solve my problem.  I think the reason is that
window-size-change-functions is called at the start of redisplay, but
the shrinking of the echo area back to 1 line only takes place later.
Hence there is no way that window-size-change-functions can then be
invoked.

In my proposed change, I change the definition of w-s-c-functions, so
that they get called both when a user action has changed window sizes
(as at present) and when redisplay changes the echo area/minibuffer
size.

> Thanks.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

From: Alan Mackenzie <acm <at> muc.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rudalics <at> gmx.at, 21869 <at> debbugs.gnu.org, pipcet <at> gmail.com
Subject: Re: bug#21869: [Patch] Redisplay: after echo area diminishes in
 size,	Follow Mode windows aren't resynchronised.
Date: Mon, 16 Nov 2015 15:03:57 +0000

Hello, Eli.

On Mon, Nov 09, 2015 at 10:50:57PM +0200, Eli Zaretskii wrote:
> > Date: Mon, 9 Nov 2015 19:42:00 +0000
> > From: Alan Mackenzie <acm <at> muc.de>
> > Cc: 21869 <at> debbugs.gnu.org, Pip Cet <pipcet <at> gmail.com>

> > > Probably bug#830 and bug#21333.

> > > Pip are you still alive?  Have your papers arrived?

Quick summary of the bug: with Follow Mode active, with a multi-line
display in the echo area, do C-f.  The echo area resizes to one line,
but the Follow Mode windows don't get resynchronised.

Quick summary of the cause: redisplay_internal calls prepare_menu_bars
(which invokes the window-size-change-functions hook) before it calls
echo_area_display (which resizes the echo area).  Thus changes to the
echo area size aren't yet in place when window-size-change-functions is
invoked.

> We had a patch in bug #21333 which was discussed and tested at
> length.  Please see if it works for your use case as well.  If not,
> please tell why not.

As I said last week, this patch didn't work, for the reasons outlined
above.

I propose the following strategy to fix the bug:

1. Call resize_mini_window from redisplay_internaal before the call to
  prepare_menu_bars.
2. Remove the call to resize_mini_window from display_echo_area_1, and
  make that function of type void.
3. Change the contract of echo_area_display, such that the echo area
  must have been set to the correct height before calling it.
4. Adapt message3_nolog (the only other function which calls
  echo_area_display) to call resize_mini_window.

As a result of these changes, any change in the size of the echo area
would be taken into account when invoking window-size-change-functions.

An advantage of this change is that a recursive invocation of
redisplay_internal inside echo_area_display could be removed, improving
performance.

If it would help, I could post an analysis to support the soundness of
the above strategy.

What do you think?

> Thanks.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

From: Alan Mackenzie <acm <at> muc.de>
To: 21869 <at> debbugs.gnu.org
Cc: rudalics <at> gmx.at, Eli Zaretskii <eliz <at> gnu.org>, pipcet <at> gmail.com,
 21333 <at> debbugs.gnu.org
Subject: Re: bug#21869: [Patch] Redisplay: after echo area diminishes in
 size, Follow Mode windows aren't resynchronised.
Date: Tue, 17 Nov 2015 17:56:23 +0000

On Mon, Nov 16, 2015 at 03:03:57PM +0000, Alan Mackenzie wrote:
> On Mon, Nov 09, 2015 at 10:50:57PM +0200, Eli Zaretskii wrote:
> > > Date: Mon, 9 Nov 2015 19:42:00 +0000
> > > From: Alan Mackenzie <acm <at> muc.de>
> > > Cc: 21869 <at> debbugs.gnu.org, Pip Cet <pipcet <at> gmail.com>

> > > > Probably bug#830 and bug#21333.

> Quick summary of the bug: with Follow Mode active, with a multi-line
> display in the echo area, do C-f.  The echo area resizes to one line,
> but the Follow Mode windows don't get resynchronised.

> Quick summary of the cause: redisplay_internal calls prepare_menu_bars
> (which invokes the window-size-change-functions hook) before it calls
> echo_area_display (which resizes the echo area).  Thus changes to the
> echo area size aren't yet in place when window-size-change-functions is
> invoked.

> I propose the following strategy to fix the bug:

> 1. Call resize_mini_window from redisplay_internal before the call to
>   prepare_menu_bars.
> 2. Remove the call to resize_mini_window from display_echo_area_1, and
>   make that function of type void.
> 3. Change the contract of echo_area_display, such that the echo area
>   must have been set to the correct height before calling it.
> 4. Adapt message3_nolog (the only other function which calls
>   echo_area_display) to call resize_mini_window.

> As a result of these changes, any change in the size of the echo area
> would be taken into account when invoking window-size-change-functions.

> An advantage of this change is that a recursive invocation of
> redisplay_internal inside echo_area_display could be removed, improving
> performance.

No it couldn't.  That invocation is not a recursive one, it's the main
call of redisplay_internal for the message functions.

Here is a patch implementing the above scheme.  It should also fix
bug#21333 (or, at least, go a long way towards fixing it):


Invoke window-size-change-functions after changing echo area height.

Fixes bug #21869 and probably bug #21333.  Separate the resizing of the echo
area from the displaying of text in it.  This allows
window-size-change-functions to be invoked after the former, but before the
latter, according to its specification.

src/xdisp.c (message3_nolog): Invoke resize_mini_window_1 before calling
echo_area_display.
(display_echo_area): Change type to (static) void.  Change contract such that
the echo area must have been resized, if nec., before calling, and that this
function doesn't resize.
(display_echo_area_1): Now always return false, since the function never
resizes.
(echo_area_display): Add extra parameter `window_height_changed_p', replacing
a local of the same name.  The function no longer resizes the echo area.
(redisplay_internal): Invoke resize_mini_window_1 before calling
prepare_menu_bars (which invokes window-size-change-functions).



diff --git a/src/xdisp.c b/src/xdisp.c
index 30dfac5..68e56b7 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -800,6 +800,9 @@ static int redisplay_mode_lines (Lisp_Object, bool);
 static void handle_line_prefix (struct it *);
 
 static void handle_stop_backwards (struct it *, ptrdiff_t);
+static bool with_echo_area_buffer (struct window *, int,
+				   bool (*)(ptrdiff_t, Lisp_Object),
+				   ptrdiff_t, Lisp_Object);
 static void unwind_with_echo_area_buffer (Lisp_Object);
 static Lisp_Object with_echo_area_buffer_unwind_data (struct window *);
 static bool current_message_1 (ptrdiff_t, Lisp_Object);
@@ -815,7 +818,7 @@ static void push_it (struct it *, struct text_pos *);
 static void iterate_out_of_display_property (struct it *);
 static void pop_it (struct it *);
 static void redisplay_internal (void);
-static void echo_area_display (bool);
+static void echo_area_display (bool, bool);
 static void redisplay_windows (Lisp_Object);
 static void redisplay_window (Lisp_Object, bool);
 static Lisp_Object redisplay_window_error (Lisp_Object);
@@ -10234,8 +10237,10 @@ message3_nolog (Lisp_Object m)
       /* Get the frame containing the mini-buffer
 	 that the selected frame is using.  */
       Lisp_Object mini_window = FRAME_MINIBUF_WINDOW (sf);
+      struct window *mw = XWINDOW (mini_window);
       Lisp_Object frame = XWINDOW (mini_window)->frame;
       struct frame *f = XFRAME (frame);
+      bool window_height_changed_p;
 
       if (FRAME_VISIBLE_P (sf) && !FRAME_VISIBLE_P (f))
 	Fmake_frame_visible (frame);
@@ -10253,7 +10258,12 @@ message3_nolog (Lisp_Object m)
 	clear_message (true, true);
 
       do_pending_window_change (false);
-      echo_area_display (true);
+      if (window_height_changed_p =
+	  with_echo_area_buffer (mw, display_last_displayed_message_p,
+				 resize_mini_window_1,
+				 (intptr_t) mw, Qt))
+	FRAME_WINDOW_SIZES_CHANGED (sf) = true;
+      echo_area_display (true, window_height_changed_p);
       do_pending_window_change (false);
       if (FRAME_TERMINAL (f)->frame_up_to_date_hook)
 	(*FRAME_TERMINAL (f)->frame_up_to_date_hook) (f);
@@ -10711,15 +10721,15 @@ setup_echo_area_for_printing (bool multibyte_p)
 }
 
 
-/* Display an echo area message in window W.  Value is true if W's
-   height is changed.  If display_last_displayed_message_p,
-   display the message that was last displayed, otherwise
-   display the current message.  */
+/* Display an echo area message in window W.  If
+   display_last_displayed_message_p, display the message that was last
+   displayed, otherwise display the current message.  The window
+   height of W must already have been set for the message.  */
 
-static bool
+static void
 display_echo_area (struct window *w)
 {
-  bool no_message_p, window_height_changed_p;
+  bool no_message_p;
 
   /* Temporarily disable garbage collections while displaying the echo
      area.  This is done because a GC can print a message itself.
@@ -10735,24 +10745,22 @@ display_echo_area (struct window *w)
   bool i = display_last_displayed_message_p;
   no_message_p = NILP (echo_area_buffer[i]);
 
-  window_height_changed_p
-    = with_echo_area_buffer (w, display_last_displayed_message_p,
-			     display_echo_area_1,
-			     (intptr_t) w, Qnil);
+  with_echo_area_buffer (w, display_last_displayed_message_p,
+			 display_echo_area_1,
+			 (intptr_t) w, Qnil);
 
   if (no_message_p)
     echo_area_buffer[i] = Qnil;
 
   unbind_to (count, Qnil);
-  return window_height_changed_p;
 }
 
 
 /* Helper for display_echo_area.  Display the current buffer which
    contains the current echo area message in window W, a mini-window,
-   a pointer to which is passed in A1.  A2..A4 are currently not used.
-   Change the height of W so that all of the message is displayed.
-   Value is true if height of W was changed.  */
+   a pointer to which is passed in A1.  The height of W must already
+   have been set to the correct height for the message.  Always
+   returns false.  */
 
 static bool
 display_echo_area_1 (ptrdiff_t a1, Lisp_Object a2)
@@ -10767,11 +10775,6 @@ display_echo_area_1 (ptrdiff_t a1, Lisp_Object a2)
      here.  */
   forget_escape_and_glyphless_faces ();
 
-  /* Do this before displaying, so that we have a large enough glyph
-     matrix for the display.  If we can't get enough space for the
-     whole text, display the last N lines.  That works by setting w->start.  */
-  bool window_height_changed_p = resize_mini_window (w, false);
-
   /* Use the starting position chosen by resize_mini_window.  */
   SET_TEXT_POS_FROM_MARKER (start, w->start);
 
@@ -10780,7 +10783,7 @@ display_echo_area_1 (ptrdiff_t a1, Lisp_Object a2)
   XSETWINDOW (window, w);
   try_window (window, start, 0);
 
-  return window_height_changed_p;
+  return false;
 }
 
 
@@ -11196,16 +11199,17 @@ clear_garbaged_frames (void)
 }
 
 
-/* Redisplay the echo area of the selected frame.  If UPDATE_FRAME_P, update
-   selected_frame.  */
+/* Redisplay the echo area of the selected frame.  If UPDATE_FRAME_P,
+   update selected_frame.  WINDOW_HEIGHT_CHANGED_P states whether the
+   echo area's height has just been changed.  It is ignored unless
+   UPDATE_FRAME_P is true.  */
 
 static void
-echo_area_display (bool update_frame_p)
+echo_area_display (bool update_frame_p, bool window_height_changed_p)
 {
   Lisp_Object mini_window;
   struct window *w;
   struct frame *f;
-  bool window_height_changed_p = false;
   struct frame *sf = SELECTED_FRAME ();
 
   mini_window = FRAME_MINIBUF_WINDOW (sf);
@@ -11230,7 +11234,7 @@ echo_area_display (bool update_frame_p)
   if (!NILP (echo_area_buffer[0]) || minibuf_level == 0)
     {
       echo_area_window = mini_window;
-      window_height_changed_p = display_echo_area (w);
+      display_echo_area (w);
       w->must_be_updated_p = true;
 
       /* Update the display, unless called from redisplay_internal.
@@ -13497,6 +13501,19 @@ redisplay_internal (void)
   /* Clear frames marked as garbaged.  */
   clear_garbaged_frames ();
 
+  /* Resize the echo area, if needed, before the invocation of
+     window-size-change-functions.  */
+  {
+    Lisp_Object mini_window = FRAME_MINIBUF_WINDOW (sf);
+    struct window *mw = XWINDOW (mini_window);
+
+    if (!MINI_WINDOW_P (XWINDOW (selected_window))
+	&& with_echo_area_buffer (mw, display_last_displayed_message_p,
+				  resize_mini_window_1,
+				  (intptr_t) mw, Qnil))
+      FRAME_WINDOW_SIZES_CHANGED (sf) = true;
+  }
+
   /* Build menubar and tool-bar items.  */
   if (NILP (Vmemory_full))
     prepare_menu_bars ();
@@ -13534,7 +13551,7 @@ redisplay_internal (void)
 	     echo-area doesn't show through.  */
 	  && !MINI_WINDOW_P (XWINDOW (selected_window))))
     {
-      echo_area_display (false);
+      echo_area_display (false, false);
 
       if (message_cleared_p)
 	update_miniwindow_p = true;



-- 
Alan Mackenzie (Nuremberg, Germany).

Message #37 received at 21869-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: 21333-done <at> debbugs.gnu.org, 21869-done <at> debbugs.gnu.org
Subject: Re: bug#19576: write-file writes the wrong buffer
Date: Sat, 21 Nov 2015 18:02:39 +0200

> Date: Sat, 21 Nov 2015 15:56:58 +0000
> Cc: 19576 <at> debbugs.gnu.org, andlind <at> gmail.com, juri <at> linkov.net
> From: Alan Mackenzie <acm <at> muc.de>
> 
> Hello, Eli.
> 
> On Sat, Nov 21, 2015 at 01:35:02PM +0200, Eli Zaretskii wrote:
> > > Date: Thu, 19 Nov 2015 18:03:39 +0200
> > > From: Eli Zaretskii <eliz <at> gnu.org>
> > > Cc: 19576 <at> debbugs.gnu.org, andlind <at> gmail.com, juri <at> linkov.net
> 
> > > > Date: Wed, 18 Nov 2015 23:23:04 +0000
> > > > Cc: martin rudalics <rudalics <at> gmx.at>, juri <at> linkov.net, andlind <at> gmail.com,
> > > >   19576 <at> debbugs.gnu.org
> > > > From: Alan Mackenzie <acm <at> muc.de>
> 
> > > > > Could you try a simpler patch below?  It seems to fix both your test
> > > > > case and the one originally reported in bug#21333.
> 
> > > > It does indeed fix my test case (I haven't tried it on #21333).  However
> > > > it violates the specification of window-size-change-functions, which
> > > > says that the hook is called _before_ redisplay, not after it has
> > > > started.  I suppose one could argue over what "redisplay" means here,
> > > > but intuitively I would say it is the putting of glyphs into matrices.
> 
> > > "Redisplay" is indeed not defined well enough, but the only reasonable
> > > interpretation of "before redisplay" is that it happens before the
> > > call to redisplay_internal.  And this is false for your suggested
> > > solution as well.  It is false even by your definition, because
> > > prepare_menu_bars already manipulates the glyph matrices, the ones it
> > > creates for the tool bar (and also menu bar on some display types).
> > > And display_echo_area also manipulates glyph matrices (it calls
> > > try_window).
> 
> > > Which is only logical for an event that by itself is triggered as part
> > > of redisplay!  It's redisplay that decides to resize the mini-window,
> > > so calling the hook after that decision _cannot_ possibly count as
> > > being "before redisplay".
> 
> > > IOW, once we, by popular demand, decided to call
> > > window-size-change-functions when the mini-window is resized, we
> > > invalidated that specification.  All the other callers of this hook
> > > are not part of a redisplay cycle, but this one is, and cannot be
> > > anywhere else.
> 
> > > So no matter what change we eventually install, the documentation of
> > > the hook needs to be amended to say that it's called "before redisplay
> > > or at the beginning of a redisplay cycle", and maybe also mention that
> > > the second case is when the mini-window is resized.
> 
> > No further comments, so I've committed the changes I posted here
> > earlier.  I also modified the documentation to be consistent with what
> > the code does.
> 
> Thanks.
> 
> > Please tell me if this bug and bug#21333 could now be closed, or if
> > there are any leftovers.
> 
> I don't think this fix concerns #19576.  The discussion of #21869 seems,
> somehow, to have moved to here.
> 
> But I think that #21333 can be closed, and #21869 certainly can be; both
> of these were about window-size-change-functions not getting called for
> echo area size changes.

Closing.

Previous Next

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