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

[Aaron Jensen]

Depending on what "slow down to a crawl" means exactly in practice, I think the reason is that it would cripple a feature. I don't know how many people use scroll-margin, but I've used it for years. I suppose I just would have to choose between precision scrolling and scroll margin, but I would have to choose between them to support something that doesn't matter to me: scrolling with images. 

It also introduces additional complexity and variation in the scrolling code, which in general, means higher overall maintenance costs (not that it's my role to police this in Emacs). 

I gather that it is redisplay that attempts to reconcile scroll-margin, is that correct? 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), 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.

Aaron

On Sat, Oct 28, 2023 at 4:42 AM, Eli Zaretskii <eliz@gnu.org> wrote:

From: Po Lu <luangruo@yahoo.com>
Cc: aaronjensen@gmail.com, 66769@debbugs.gnu.org
Date: Sat, 28 Oct 2023 16:34:17 +0800

Eli Zaretskii <eliz@gnu.org> writes:

And what are the problems in computing this target point in the particular case described here?

It should be outside the scroll margin, so additional layout computations must be performed after scrolling, compounding those performed beforehand to establish the new window start.

Even if it's done "only in this case"? It should slow down only this case, no?

And what exactly is the crucial difference between "this case" and the other cases, where scrolling works correctly?

The distinction is that scroll-margin is set.

That's what I thought, and which is why I asked whether calling the slow posn-at-point only when scroll-margin is non-zero wouldn't be the proper solution, as it should only slow down scrolling for those users who set scroll-margin. Or what am I missing?