Re: Set-window-vscroll sometimes doesn't work

[Eli Zaretskii <eliz@gnu.org>]

> From: Yuan Fu <casouri@gmail.com>
> Date: Thu, 22 Oct 2020 00:16:04 -0400
> Cc: help-gnu-emacs@gnu.org
> 
> Ok, I looked at redisplay_window, and it zeros out vscroll if force_start is true, that explains my initial
> question. After reading the function, it seems that setting window-start is the primary way to scroll and to
> produce the glyph matrix to display. IIUC this is how window-start and vscroll works together in window
> redisplay: we have a window-start -> try window -> start_display on window-start -> it_initialize on
> window-start -> it->current-y adjusted according to vscroll -> back to try window -> while (it.current_y <
> it.last_visible_y): produce glyph rows. This doesn’t seem to be too contradictory, and scrolling by setting
> window-start and add sub-line adjustment with vscroll seems to be complaint with the redisplay logic. What
> am I missing?

You are missing the use cases where the display element that is taller
than the normal text is not an image, but something else.  For
example, text displayed with a very large font.  In this other use
case, starting display with a non-zero vscroll when the Lisp program
forced window-start will produce text part of which cannot be read,
because too much of the characters is off-screen.

This is why setting window-start zeroes out vscroll: Emacs wants to
make sure that in this case the entire screen line that starts at
window-start will be fully visible.