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

[Aaron Jensen]

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