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: Eli Zaretskii <eliz <at> gnu.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 66769 <at> debbugs.gnu.org, aaronjensen <at> gmail.com
Subject: bug#66769: 30.0.50; pixel-scroll-precision-mode and scroll-margin regression
Date: Sat, 28 Oct 2023 09:43:19 +0300

> Cc: 66769 <at> debbugs.gnu.org
> Date: Sat, 28 Oct 2023 10:17:51 +0800
> From:  Po Lu via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> Aaron Jensen <aaronjensen <at> gmail.com> writes:
> 
> > Commit 1da4fca0647ebf1d5d6f12817301a17661560810 caused a regression of
> > bug#52231
> >
> > The repro is the same:
> >
> > (progn (setq scroll-margin 4)
> >        (pixel-scroll-precision-mode))
> >
> > And scroll down a buffer with mouse wheel.
> >
> > The buffer does not scroll properly, it jumps back unless you scroll
> > fast enough.
> 
> Hmm, I'm not certain what the solution to this should be.
> 
> For images to scroll properly, the "target point" must be derived from
> whether the point is visible after scrolling, instead of outside a set
> number of rows from the window start or end.  Yet the latter information
> is mandatory if the scroll margin is to be taken into account, and no
> function supplies both besides posn-at-point, which is much too slow.

What is the "target point" in the above text? target for what?

> The immediate remedy is to restore the old code when scroll-margin is in
> effect and document the consequent incapacity to scroll over large
> images as an unfortunate corollary.  Is that acceptable by you?

Why not use the too-slow posn-at-point, but only in this case?

Previous Next

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