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

[Po Lu]

Aaron Jensen <aaronjensen@gmail.com> writes:

> 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?

posn-at-point is presently not used by p-s-p-m.

> 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.

Yes, because redisplay is the process responsible for enforcing the
scroll margin in the process of maintaining point within the window.

> 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?

The problem is two-fold: a position must be calculated that is
scroll-margin rows from the window start or end, but that position must
be replaced by the position of the row farthest from the window boundary
opposite the direction being scrolled in if there are fewer than
scroll-margin rows displayed in the window _after_ the scroll completes.