GNU bug report logs - #57970
29.0.50; Create new defgroup for pixel-scroll.el

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: larsi <at> gnus.org, 57970 <at> debbugs.gnu.org, stefankangas <at> gmail.com
Subject: bug#57970: 29.0.50; Create new defgroup for pixel-scroll.el
Date: Mon, 11 Sep 2023 16:49:59 +0300

> From: Po Lu <luangruo <at> yahoo.com>
> Cc: stefankangas <at> gmail.com,  larsi <at> gnus.org,  57970 <at> debbugs.gnu.org
> Date: Mon, 11 Sep 2023 20:45:55 +0800
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > So maybe we should document that one is better for wheels, the other
> > for touchpads?  And maybe even (gasp!) rename
> > pixel-scroll-precision-mode to something like touchpad-scroll-mode?
> 
> pixel-scroll-mode isn't better for wheel mice as long as you actually
> tell p-s-p-m that you use one, so that assessment isn't really correct.
> 
> pixel-scroll-mode's principal failings are that it bails out when a
> wheel event arrives while scrolling is taking place, it always scrolls
> by a set number of lines, and it is slow.  p-s-p-m experiences none of
> these problems.

It sounds like your comments actually agree with my suggestions ;-)

To clarify, I didn't mean that pixel-scroll-precision-mode _cannot_ be
used with wheels, I just said pixel-scroll-mode is _better_ there
(because it requires no tricky configuration); conversely, for
touchpads, pixel-scroll-precision-mode produces a much better UX OOTB.

This particular discussion is about two modes that have very similar
names.  I think explaining the strengths and weaknesses (even if they
are minor and can be overcome, given enough efforts) goes at least
some way towards resolving user confusion about these two, and
changing the name, even if not 110% accurate, is even better.

Previous Next

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