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

[Eli Zaretskii]

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Sat, 28 Oct 2023 05:33:06 -0700
> Cc: Po Lu <luangruo@yahoo.com>, 66769@debbugs.gnu.org
> 
> I gather that it is redisplay that attempts to reconcile scroll-margin, is 
> that correct?

Yes, of course.  Moreover, the scrolling itself is done by the display
engine, and it keeps point out of the scroll-margin as part of that.

> If so, is there a way
> to flip scroll-margin on its head such that it is only intentional point 
> movement operations that cause
> scroll-margin to trigger scrolling? i.e., when doing pixel scrolling, you 
> either temporarily disable the
> scroll margin (which has the negative impact of once a user does move the 
> point, it will cause a
> jump),

Maybe someone will come up with some clever trick, but if so, it will
be very fragile.

You seem to think that redisplay knows what moved point, or more
generally why there should be some change to be done on display, like
whether it was the fact that point moved or something else.  But
that's not what happens.  What actually happens is that redisplay is
called whenever Emacs is idle, and it (redisplay) then needs to decide
whether something should be done to redraw some part of the Emacs
display, and if so, which parts and how to do that.  The reason _why_
the display needs to be updated is mostly not known to the display
engine, at least not in terms of user commands, which is the level
which you seem to have in mind.

Moreover, even if by some trick we succeed to "persuade" redisplay to
refrain from some action, the very next redisplay cycle will almost
certainly "forget" that reason and do what we don't want anyway.  For
example, if redisplay finds that point is inside the scroll margin, it
will scroll the window or move point so as to have point out of
scroll-margin.  So any such temporary measure, even if it succeeds,
will be almost immediately undone.

> or, after a pixel scroll is done, you move the point to be outside of the 
> bounds of the scroll
> margin, rather than allowing the redisplay to change the scroll position. 
> Perhaps that is what you are
> describing and is what would require posn-at-point.

AFAIU, this is what Po Lu was thinking about, and this is what he
said would be too slow.