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

Previous Next

Package: emacs;

Reported by: Aaron Jensen <aaronjensen <at> gmail.com>

Date: Fri, 27 Oct 2023 05:02:01 UTC

Severity: normal

Merged with 68196

Found in version 30.0.50

Full log


View this message in rfc822 format

From: Po Lu <luangruo <at> yahoo.com>
To: Aaron Jensen <aaronjensen <at> gmail.com>
Cc: 66769 <at> debbugs.gnu.org
Subject: bug#66769: 30.0.50; pixel-scroll-precision-mode and scroll-margin regression
Date: Thu, 02 Nov 2023 14:16:58 +0800
Aaron Jensen <aaronjensen <at> gmail.com> writes:

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

posn-at-point is presently not used by p-s-p-m.

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

Yes, because redisplay is the process responsible for enforcing the
scroll margin in the process of maintaining point within the window.

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

The problem is two-fold: a position must be calculated that is
scroll-margin rows from the window start or end, but that position must
be replaced by the position of the row farthest from the window boundary
opposite the direction being scrolled in if there are fewer than
scroll-margin rows displayed in the window _after_ the scroll completes.




This bug report was last modified 1 year and 168 days ago.

Previous Next


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