GNU bug report logs - #66769
30.0.50; pixel-scroll-precision-mode and scroll-margin regression

Previous Next

Full log

View this message in rfc822 format

From: Aaron Jensen <aaronjensen <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Po Lu <luangruo <at> yahoo.com>, 66769 <at> debbugs.gnu.org
Subject: bug#66769: 30.0.50; pixel-scroll-precision-mode and scroll-margin regression
Date: Sat, 28 Oct 2023 05:33:06 -0700

[Message part 1 (text/plain, inline)]

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 <at> gnu.org> wrote:

> From: Po Lu <luangruo <at> yahoo.com>
> Cc: aaronjensen <at> gmail.com, 66769 <at> debbugs.gnu.org
> Date: Sat, 28 Oct 2023 16:34:17 +0800
>
> Eli Zaretskii <eliz <at> 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?
>

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.