Subject: Re: bug#70038: 29.3.50; Shift up/down in buffer with images on M-x other-window with some fonts

From: martin rudalics <[email-masked]>
Date: Sun, 14 Apr 2024 10:31:15 +0200

> The (slight) harm this does is that it might make redisplay of the
 > window slightly more expensive, because it disables some
 > optimizations, like if nothing changed except the position of point.
 > Another kind of harm is what triggered this bug report: it could cause
 > us to reset the window's vscroll for now good reason, because when
 > start positions are frozen, we set the window's force_start flag, and
 > that sometimes forces us to reset vscroll.

 From looking at the code it's hard to understand what you say here.  It
might be a good idea to add this as a comment.

 > So the patch below is the only change we need to make sure the frame's
 > frozen_window_starts is reset when the mini-window is resized back?

Probably not.  If 'resize-mini-windows' is t, we never unfreeze window
starts because we don't call shrink_mini_window in that case.

 > Should it matter whether, if the minibuffer is active, we do that only
 > at the outer level of minibuffer?

It shouldn't.  Window starts would be frozen immediately as soon as the
mini window grows again.  I think that to cover most cases we should
unfreeze window starts every time the mini window gets smaller as in the
patch below.

diff --git a/src/window.c b/src/window.c
index fe26311fbb2..9c8fc12ee3e 100644
--- a/src/window.c
+++ b/src/window.c
@@ -5376,7 +5376,8 @@ grow_mini_window (struct window *w, int delta)
        struct window *r = XWINDOW (root);
        Lisp_Object grow;

-      FRAME_WINDOWS_FROZEN (f) = true;
+      FRAME_WINDOWS_FROZEN (f) = (delta > 0) ? true : false;
+
        grow = call3 (Qwindow__resize_root_window_vertically,
  		    root, make_fixnum (- delta), Qt);

martin