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: Sun, 28 Apr 2024 10:51:38 +0200
> Cc: luangruo@yahoo.com, 70038@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> 
>  > Where would you like to put the comment, and what should that comment
>  > say?
> 
> There are three issues I don't understand well in this context.  The
> first one concerns the preserve_vscroll_p flag we currently check as:
> 
>        if (!w->preserve_vscroll_p && !window_frozen_p (w))
> 	w->vscroll = 0;
> 
> Here, in all scenarios I tried, I observed that w->preserve_vscroll_p
> implies window_frozen_p (w) which IIUC means that the preserve_vscroll_p
> flag is not needed and we could simplify the above to
> 
>        if (!window_frozen_p (w))
> 	w->vscroll = 0;
> 
> What am I missing here?

I'll let Po Lu answer that, since the preserve_vscroll_p flag was
introduced to support precise pixelwise scrolling.

> The second issue is why we freeze window starts at all.  Conceptually,
> when window starts are frozen, redisplay should not change the start
> position of _any_ window whenever we enlarge the mini window.  But
> window_frozen_p returns false for the selected and minibuffer scroll
> windows.  Hence, freezing does not set force_start for these windows.
> 
> While this discrimination seems unwanted (in particular when resizing
> the echo area), it apparently doesn't matter in any of the scenarios I
> tried here - the start positions of all windows remain unchanged in
> precisely the same way regardless of whether they are selected or not.
> So IIUC we could do away with freezing as well.

Your conclusions are too drastic, IMO.  Freezing window-starts is an
advisory, not a mandatory, setting.  So the fact that it isn't always
obeyed doesn't mean it has no place: when it _is_ obeyed, it enables
some optimizations, as I described several messages up-thread.  Giving
up those optimizations when we can use them is not wise.

> I suppose that I'm missing some optimization issue here but fail to see
> what it is.

I described those optimizations in so many words in one of my previous
messages.

> The third issue is that of the optional_new_start flag: All 'recenter'
> effectively does is to calculate a new start position of a window and
> ask redisplay to apply it.  Now why does 'recenter' in particular set
> that flag and why does none of the other functions that set a window's
> start position like 'scroll-up' or 'scroll-down' set it?

Scrolling commands set force_start, which is a stronger condition than
optional_new_start.  I guess recenter doesn't have to make sure the
window starts exactly where it thinks it should, or something.

> Note that I'm not asking to revise code that works sufficiently well
> now.  But clarifying the issues I tried to sketch above in the comment
> preceding redisplay_window could be useful to better understand bugs
> like the one that triggered this thread.

I still don't know what to comment, because you seem to ask the same
questions again, although I already answered them.  So I'm probably
missing something here.  I can think about comments once you say that
you understand and agree with the explanations, but would like to see
them spelled out in comments, but not before that.