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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Mon, 15 Apr 2024 11:23:18 +0200
> Cc: luangruo@yahoo.com, 70038@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> 
>  > Did I succeed explaining the issue?
> 
> Not yet.

You asked what harm could unnecessarily frozen window-start do, and I
explained that: it causes us to run more expensive code.  Now you are
asking a different question: why do we freeze window-start points at
all?  Let me try to answer that as well.

> When we freeze window starts in the case at hand we do that to
> approximate the behavior of a 'save-window-excursion'.  But doesn't
> Emacs always try to preserve window start positions regardless of
> whether it enlarges or shrinks a window?

It does, but what it will do if the current window-start doesn't show
point depends on whether or not we take the "force_start" path.  See
below.

> So what, if possibly, could
> motivate Emacs to "willfully" change a start position?

For example, if point is not visible in the window, or is on a screen
line that is only partially visible, or is inside the scroll-margin.

> It's obvious that
> 'recenter' asks for it and sets optional_new_start.  It's already not
> clear to me why 'delete-other-windows' should want it.  So why treating
> frozen starts like asking for new start positions is still a mystery to
> me ...

See above.  Basically, anything that changes the window geometry can
potentially cause us to want to move the window-start point.

> I suppose that freezing should handle one situation only: Emacs enlarges
> the mini window, shrinks another window for that purpose and - for a
> reason that is still unclear to me as mentioned above - would like to
> change that window's start position.  To avoid that - Emacs will still
> have to change the start position to avoid that point goes off-screen -
> we set that flag.  Now it seems obvious that shrinking the mini window
> and thus enlarging another window cannot harm in this regard since
> otherwise we couldn't have reset the flag when shrinking a mini window
> as we did earlier.  Is it about making the cursor line fully visible?

Yes.  More generally, if the force_start flag is NOT set, and using
the current window-start doesn't produce point in a fully-visible
screen line and out of the scroll margins, then Emacs will try to find
a different window-start point (even recentering the window around
point if nothing else works).  By contrast, if the force_start flag
_is_ set, Emacs will instead move point to bring it inside the window,
without changing window-start.  When the window-start is frozen, we
quickly determine whether using the current window-start will leave
point inside the window, and if so, we set the force_start flag
ourselves, to prevent redisplay_window from changing window-start.

I hope this is now more clear.

>  > Is that in addition to what I suggested to do in shrink_mini_window?
> 
> It should replace it.

Hmm... I don't like leaving shrink_mini_window without the reset.

>  > Also, shouldn't we do this instead:
>  >
>  >> -      FRAME_WINDOWS_FROZEN (f) = true;
>  >> +      FRAME_WINDOWS_FROZEN (f) = (old_height + delta > min_height) ? true : false;
>  >
>  > IOW, shouldn't we unfreeze only when resizing to the default one-line
>  > height?
> 
> Since every enlarging of the mini window freezes starts again, this
> shouldn't be necessary.  But to make sure that we cover all possible
> scenarios we could use the below.

Thanks, I like this much better.  Now installed on master.