GNU bug report logs - #50269
27.2; Request: use GTK continuous scroll events for smooth touchpad scrolling

Previous Next

Package: emacs;

Reported by: Alexander Huntley <huntley.alexander <at> gmail.com>

Date: Mon, 30 Aug 2021 14:57:01 UTC

Severity: wishlist

Tags: moreinfo

Found in version 27.2

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alexander Huntley <huntley.alexander <at> gmail.com>
Cc: 50269 <at> debbugs.gnu.org
Subject: Re: bug#50269: 27.2; Request: use GTK continuous scroll events for
 smooth touchpad scrolling
Date: Tue, 31 Aug 2021 15:17:09 +0300
> From: Alexander Huntley <huntley.alexander <at> gmail.com>
> Cc: 50269 <at> debbugs.gnu.org
> Date: Mon, 30 Aug 2021 22:26:45 +0100
> 
> pixel-scroll-mode may shift the display one pixel at a time, but it
> also "snaps" the display to certain larger intervals, (integer numbers
> of lines).

I don't think I follow: what is this "snapping" you are alluding to
here?  Can you tell me how to reproduce this snapping, so I could
understand better the problem you have in mind?

> If we could use the more precise/frequent data actually coming from
> the touchpad, then the user could control the scrolling more precisely:
> instead of scrolling by n lines, the user could scroll by as little
> as a single pixel at a time.

The scrolling, whether pixel-wise or not, is performed by the Emacs
display engine; the scroll commands themselves just tell the display
engine where in buffer text to start the display of a window, and with
what "shifting offset" in pixels to display that text.  So I don't see
how using some different/more precise data will help, if all that data
tells Emacs is by how many pixels to scroll, because the actual
scrolling will still be performed by the same display engine.  If the
display engine is unable to scroll smoothly, for some reason, using
different data source to compute how many pixels to scroll will not
help.

So we must first understand what is wrong with pixel-scroll-mode,
because all it does with the "normal" (a.k.a. "imprecise") scroll
commands coming from the touchpad is compute how many pixels to
scroll, and the default is AFAIR to scroll a small number of pixels
per wheel notch (you can customize it to make it exactly 1 pixel).

Therefore, I hope you could help us understand what is wrong with the
pixel-wise scrolling in the display engine, as it is used by
pixel-scroll-mode.  TIA.




This bug report was last modified 2 years and 244 days ago.

Previous Next


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