GNU bug report logs - #70038
29.3.50; Shift up/down in buffer with images on M-x other-window with some fonts

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: luangruo <at> yahoo.com, 70038 <at> debbugs.gnu.org
Subject: bug#70038: 29.3.50; Shift up/down in buffer with images on M-x other-window with some fonts
Date: Sat, 13 Apr 2024 13:10:32 +0300

> Date: Mon, 8 Apr 2024 11:07:50 +0200
> Cc: r.diaz <at> uam.es, luangruo <at> yahoo.com, rahguzar <at> zohomail.eu,
>  rdiaz02 <at> gmail.com, 70038 <at> debbugs.gnu.org
> From: martin rudalics <rudalics <at> gmx.at>
> 
> A possibly heretical question is in which way freezing start positions
> permanently can harm.  IIUC, after a minibuffer interaction, currently
> the only way to unfreeze start positions is to resize the minibuffer
> window and trigger the corresponding call in shrink_mini_window.  But
> setting the start position of any window while a minibuffer interaction
> is going on seems to work here without problems.

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.

> That was silly.  minibuffer_unwind seems to care only about replacing
> one minibuffer with another.  read_minibuf_unwind already should handle
> this here (don't ask me what a future_mini_window is)
> 
>    /* When we get to the outmost level, make sure we resize the
>       mini-window back to its normal size.  */
>    if (minibuf_level == 0
>        || !EQ (selected_frame, WINDOW_FRAME (XWINDOW (future_mini_window))))
>      resize_mini_window (XWINDOW (minibuf_window), 0);
> 
> The only problem is that if the mini window was _not_ enlarged,
> shrink_mini_window won't unfreeze starts.  Unconditionally unfreezing
> start positions there as I mentioned in my first mail should fix that.

Thanks.

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?

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

diff --git a/src/window.c b/src/window.c
index fe26311..0945b24 100644
--- a/src/window.c
+++ b/src/window.c
@@ -5407,13 +5407,13 @@ shrink_mini_window (struct window *w)
 
   eassert (MINI_WINDOW_P (w));
 
+  FRAME_WINDOWS_FROZEN (f) = false;
   if (delta > 0)
     {
       Lisp_Object root = FRAME_ROOT_WINDOW (f);
       struct window *r = XWINDOW (root);
       Lisp_Object grow;
 
-      FRAME_WINDOWS_FROZEN (f) = false;
       grow = call3 (Qwindow__resize_root_window_vertically,
 		    root, make_fixnum (delta), Qt);
 

Previous Next

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