bug#66769: 30.0.50; pixel-scroll-precision-mode and scroll-margin regression

[Aaron Jensen <aaronjensen@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1669 bytes --]

On Fri, Oct 27, 2023 at 10:17 PM, Po Lu <luangruo@yahoo.com> wrote:

> Aaron Jensen <aaronjensen@gmail.com> writes:
>
> Commit 1da4fca0647ebf1d5d6f12817301a17661560810 caused a regression of
> bug#52231
>
> The repro is the same:
>
> (progn (setq scroll-margin 4)
> (pixel-scroll-precision-mode))
>
> And scroll down a buffer with mouse wheel.
>
> The buffer does not scroll properly, it jumps back unless you scroll fast
> enough.
>
> Hmm, I'm not certain what the solution to this should be.
>
> For images to scroll properly, the "target point" must be derived from
> whether the point is visible after scrolling, instead of outside a set
> number of rows from the window start or end. Yet the latter information is
> mandatory if the scroll margin is to be taken into account, and no function
> supplies both besides posn-at-point, which is much too slow.
>
> The immediate remedy is to restore the old code when scroll-margin is in
> effect and document the consequent incapacity to scroll over large images
> as an unfortunate corollary. Is that acceptable by you?
>

It looks like the current code uses posn-at-point already, yes? What is it
that would make it too slow to use it again for the point? I'm trying to
understand the code and making some headway, but it's still not totally
clear what's happening and why. It does seem that if you force a redisplay
after the set-window-vscroll, the window-start will move in the case that
it butts up against the scroll margin.

Is there a fast way to compute the position that is scroll-margin lines
away from the window start and then compare the point to that? Or is the
bigger problem when scrolling up?

Aaron

[-- Attachment #2: Type: text/html, Size: 2738 bytes --]