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

Previous Next

Full log

Message #23 received at 66769 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 66769 <at> debbugs.gnu.org, aaronjensen <at> gmail.com
Subject: Re: bug#66769: 30.0.50; pixel-scroll-precision-mode and
 scroll-margin regression
Date: Sat, 28 Oct 2023 11:42:15 +0300

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

Previous Next

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