GNU bug report logs - #51886
29.0.50; pixel-scroll-mode garbage collects like crazy

Previous Next

To reply to this bug, email your comments to 51886 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

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

From: Po Lu <luangruo <at> yahoo.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.50; pixel-scroll-mode garbage collects like crazy
Date: Tue, 16 Nov 2021 15:21:31 +0800

Starting from `emacs -Q', do M-x pixel-scroll-mode RET, then configure
it as follows:

    (setq pixel-dead-time 0)
    (setq pixel-resolution-fine-flag 1)
    (setq garbage-collection-messages t)

Then scroll the display with the mouse wheel.  It will garbage collect
like crazy, leading to a great deal of stuttering (in emacs-28 as well).

I want to reuse most of the code in pixel-scroll.el for XInput2 pixel
scrolling, but this is holding me back, as the excessive garbage
collection makes it completely unusable.

Thanks.

In GNU Emacs 29.0.50 (build 74, x86_64-pc-linux-gnu, GTK+ Version 3.24.30, cairo version 1.17.4)
 of 2021-11-16 built on trinity
Repository revision: 9bad69e3fa83c0671322011ed4f563c0ff6d4892
Repository branch: feature/xinput2
Windowing system distributor 'The X.Org Foundation', version 11.0.12101002
System Description: Fedora 34 (Workstation Edition)

Configured using:
 'configure --with-xwidgets'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON
LCMS2 LIBSELINUX LIBSYSTEMD LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PNG
RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS WEBP X11 XDBE XIM
XPM XWIDGETS GTK3 ZLIB

Important settings:
  value of $LANG: en_GB.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  pixel-scroll-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media rmc puny
dired dired-loaddefs rfc822 mml mml-sec epa derived epg rfc6068
epg-config gnus-util rmail rmail-loaddefs auth-source cl-seq eieio
eieio-core cl-macs eieio-loaddefs password-cache json map
text-property-search seq gv byte-opt bytecomp byte-compile cconv
mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils
mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr
mail-utils time-date subr-x info cus-start cus-load pixel-scroll
help-mode cl-loaddefs cl-lib iso-transl tooltip eldoc paren electric
uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite emoji-zwj charscript charprop case-table
epa-hook jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice
button loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote threads xwidget-internal dbusbind
inotify lcms2 dynamic-setting system-font-setting font-render-setting
cairo move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 136507 9602)
 (symbols 48 8087 1)
 (strings 32 29616 2128)
 (string-bytes 1 988001)
 (vectors 16 14616)
 (vector-slots 8 197714 10580)
 (floats 8 32 44)
 (intervals 56 20288 5)
 (buffers 992 13))

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 51886 <at> debbugs.gnu.org
Subject: Re: bug#51886: 29.0.50; pixel-scroll-mode garbage collects like crazy
Date: Tue, 16 Nov 2021 15:05:32 +0200

> Date: Tue, 16 Nov 2021 15:21:31 +0800
> From:  Po Lu via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> Starting from `emacs -Q', do M-x pixel-scroll-mode RET, then configure
> it as follows:
> 
>     (setq pixel-dead-time 0)
>     (setq pixel-resolution-fine-flag 1)
>     (setq garbage-collection-messages t)
> 
> Then scroll the display with the mouse wheel.  It will garbage collect
> like crazy, leading to a great deal of stuttering (in emacs-28 as well).
> 
> I want to reuse most of the code in pixel-scroll.el for XInput2 pixel
> scrolling, but this is holding me back, as the excessive garbage
> collection makes it completely unusable.

Did you try to figure out which part of the code produces most of the
garbage?

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

From: Po Lu <luangruo <at> yahoo.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 51886 <at> debbugs.gnu.org
Subject: Re: bug#51886: 29.0.50; pixel-scroll-mode garbage collects like crazy
Date: Tue, 16 Nov 2021 21:17:55 +0800

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Date: Tue, 16 Nov 2021 15:21:31 +0800
>> From:  Po Lu via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>> 
>> Starting from `emacs -Q', do M-x pixel-scroll-mode RET, then configure
>> it as follows:
>> 
>>     (setq pixel-dead-time 0)
>>     (setq pixel-resolution-fine-flag 1)
>>     (setq garbage-collection-messages t)
>> 
>> Then scroll the display with the mouse wheel.  It will garbage collect
>> like crazy, leading to a great deal of stuttering (in emacs-28 as well).
>> 
>> I want to reuse most of the code in pixel-scroll.el for XInput2 pixel
>> scrolling, but this is holding me back, as the excessive garbage
>> collection makes it completely unusable.
>
> Did you try to figure out which part of the code produces most of the
> garbage?

Here's the report from the memory profiler scrolling down (emacs)Top
with those settings applied in Info:

    347,738,992  30% + beginning-of-visual-line
    203,047,297  17% + end-of-visual-line
    170,995,572  14% + pixel-posn-y-at-point
    143,277,076  12% + pixel-visual-line-height
    113,156,817   9% + pixel-visible-pos-in-window
     99,928,040   8% + if
     11,567,121   1% + pixel-line-height
      9,885,201   0% + pixel--whistlestop-pixel-up
      9,471,180   0% + pixel--whistlestop-line-up
      7,420,310   0% + redisplay
      5,325,728   0% + window-current-scroll-bars
      4,814,936   0% + pixel-scroll-up
      4,092,960   0% + pixel-eob-at-top-p
      3,597,328   0% + profiler-stop
      2,783,202   0% + unless
      2,146,848   0% + window-edges
      1,586,384   0% + sit-for
      1,448,085   0% + window-inside-pixel-edges
      1,297,072   0% + pixel-point-at-top-p
      1,196,572   0% + pixel-scroll-pixel-up
        978,872   0% + mouse-wheel--get-scroll-window
        268,778   0% + apply
        220,291   0% + eval
        166,360   0% + c-type-finder-timer-func
        155,896   0% + timer--time-less-p
        144,822   0% + read-from-minibuffer
        117,312   0% + execute-extended-command
        105,840   0% + timer--time-setter
        102,392   0% + timer-relative-time
         95,312   0% + timer-create
         94,648   0% + pixel-scroll-in-rush-p
         83,304   0% + Info-check-pointer
         66,944   0% + mwheel-scroll
         65,968   0% + Info-extract-pointer
         38,435   0% + completing-read-default
         38,008   0% + frame-focus-state
         32,736   0% + funcall-interactively
         29,768   0% + posn-at-point
         22,176   0% + timer-activate
         17,952   0% + window-pixel-edges
         17,136   0% + call-interactively
         15,840   0% + redisplay_internal (C function)
         12,664   0% + command-execute
         12,432   0% + jit-lock--run-functions
         11,248   0% + menu-bar-update-buffers-1
          8,288   0% + #<compiled 0x19a292a7afa00b7d>
          8,184   0% + x-gtk-map-stock
          7,494   0% + window-frame
          7,432   0% + pos-visible-in-window-p
          7,312   0% + jit-lock-fontify-now
          6,336   0% + #<compiled 0xa2ad9af8e9ade27>
          6,336   0% + user-error
          6,336   0% + undo-auto--boundaries
          3,810   0% + line-number-at-pos
          2,120   0% + scroll-up
          1,959   0%   timer-event-handler
          1,921   0% + fboundp
          1,905   0% + window-scroll-bars
          1,905   0% + constrain-to-field
          1,905   0%   clear-minibuffer-message
          1,905   0% + frame-live-p
          1,863   0% + window-margins
          1,863   0% + line-pixel-height
          1,863   0% + mwheel-event-button
          1,863   0% + profiler-memory-running-p
          1,056   0% + handle-focus-in
          1,056   0% + minibuffer-mode
          1,056   0% + #<compiled 0x1d710e244bc5248e>
          1,056   0% + menu-bar-update-buffers
          1,056   0% + keymap-canonicalize
          1,056   0% + run-hooks
          1,024   0%   mouse-fixup-help-message
            912   0% + count-lines
            631   0% + profiler-start
             21   0% + generate-new-buffer

And here's the entire profile:

[profile (application/octet-stream, attachment)]

[Message part 3 (text/plain, inline)]

I hope this helps, thanks.

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

From: Robert Pluim <rpluim <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Po Lu <luangruo <at> yahoo.com>, 51886 <at> debbugs.gnu.org
Subject: Re: bug#51886: 29.0.50; pixel-scroll-mode garbage collects like crazy
Date: Tue, 16 Nov 2021 14:28:23 +0100

>>>>> On Tue, 16 Nov 2021 15:05:32 +0200, Eli Zaretskii <eliz <at> gnu.org> said:

    >> Date: Tue, 16 Nov 2021 15:21:31 +0800
    >> From:  Po Lu via "Bug reports for GNU Emacs,
    >> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
    >> 
    >> Starting from `emacs -Q', do M-x pixel-scroll-mode RET, then configure
    >> it as follows:
    >> 
    >> (setq pixel-dead-time 0)
    >> (setq pixel-resolution-fine-flag 1)
    >> (setq garbage-collection-messages t)
    >> 
    >> Then scroll the display with the mouse wheel.  It will garbage collect
    >> like crazy, leading to a great deal of stuttering (in emacs-28 as well).
    >> 
    >> I want to reuse most of the code in pixel-scroll.el for XInput2 pixel
    >> scrolling, but this is holding me back, as the excessive garbage
    >> collection makes it completely unusable.

    Eli> Did you try to figure out which part of the code produces most of the
    Eli> garbage?

I suspect itʼs the bit that counts from k to n by generating a list of
the integers from k to n and then running dolist over that.

As an aside, that code also does a lot of (sit-for 0), which I seem to
remember can trigger redisplay? Perhaps it should only do that when it
really wants to pause.

Robert
-- 

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 51886 <at> debbugs.gnu.org
Subject: Re: bug#51886: 29.0.50; pixel-scroll-mode garbage collects like crazy
Date: Tue, 16 Nov 2021 15:37:00 +0200

> From: Po Lu <luangruo <at> yahoo.com>
> Cc: 51886 <at> debbugs.gnu.org
> Date: Tue, 16 Nov 2021 21:17:55 +0800
> 
> > Did you try to figure out which part of the code produces most of the
> > garbage?
> 
> Here's the report from the memory profiler scrolling down (emacs)Top
> with those settings applied in Info:

The so-called "memory profiler" doesn't actually collect memory usage
statistics, so it's useless for this job.

I don't think we have tools ready for the job.  I suggest to
instrument the code involved in this and see what kind of objects get
consed the most, and by which code.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: luangruo <at> yahoo.com, 51886 <at> debbugs.gnu.org
Subject: Re: bug#51886: 29.0.50; pixel-scroll-mode garbage collects like crazy
Date: Tue, 16 Nov 2021 15:38:36 +0200

> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: Po Lu <luangruo <at> yahoo.com>,  51886 <at> debbugs.gnu.org
> Date: Tue, 16 Nov 2021 14:28:23 +0100
> 
> I suspect itʼs the bit that counts from k to n by generating a list of
> the integers from k to n and then running dolist over that.

Maybe, but I think we want a more direct evidence.

> As an aside, that code also does a lot of (sit-for 0), which I seem to
> remember can trigger redisplay? Perhaps it should only do that when it
> really wants to pause.

It doesn't want to pause, it wants to trigger redisplay.  Without that
the stuff will not work.

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

From: Po Lu <luangruo <at> yahoo.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Robert Pluim <rpluim <at> gmail.com>, 51886 <at> debbugs.gnu.org
Subject: Re: bug#51886: 29.0.50; pixel-scroll-mode garbage collects like crazy
Date: Tue, 16 Nov 2021 21:41:29 +0800

Eli Zaretskii <eliz <at> gnu.org> writes:

>> I suspect itʼs the bit that counts from k to n by generating a list of
>> the integers from k to n and then running dolist over that.
>
> Maybe, but I think we want a more direct evidence.

Sadly, it's not the case here.  Rewriting `pixel--whistlestop-pixel-up'
to not cons (such as with number-sequence) yields no visible
improvement.

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

From: Robert Pluim <rpluim <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Po Lu <luangruo <at> yahoo.com>, 51886 <at> debbugs.gnu.org
Subject: Re: bug#51886: 29.0.50; pixel-scroll-mode garbage collects like
 crazy, Re: bug#51886: 29.0.50; pixel-scroll-mode garbage collects like
 crazy
Date: Tue, 16 Nov 2021 15:35:11 +0100

>>>>> On Tue, 16 Nov 2021 15:38:36 +0200, Eli Zaretskii <eliz <at> gnu.org> said:

    Eli> It doesn't want to pause, it wants to trigger redisplay.  Without that
    Eli> the stuff will not work.

Replacing them all with
          (when (not (zerop pixel-wait))
             (sit-for pixel-wait)

doesnʼt seem to have broken anything....

>>>>> On Tue, 16 Nov 2021 21:41:29 +0800, Po Lu <luangruo <at> yahoo.com> said:

    Po> Eli Zaretskii <eliz <at> gnu.org> writes:

    >>> I suspect itʼs the bit that counts from k to n by generating a list of
    >>> the integers from k to n and then running dolist over that.
    >> 
    >> Maybe, but I think we want a more direct evidence.

    Po> Sadly, it's not the case here.  Rewriting `pixel--whistlestop-pixel-up'
    Po> to not cons (such as with number-sequence) yields no visible
    Po> improvement.

Hmm. Changing the catch/throw in `pixel-scroll-up' to

          (while (and (pixel-point-at-top-p amt)
                      (>= (vertical-motion 1) 1)))

seems to help. As does removing mode-line-remote from mode-line-format
(the profiler said we were calling `file-remote-p' a lot).

Robert
-- 

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 51886 <at> debbugs.gnu.org
Subject: Re: bug#51886: 29.0.50; pixel-scroll-mode garbage collects like crazy
Date: Tue, 20 Sep 2022 17:16:33 +0200

Po Lu <luangruo <at> yahoo.com> writes:

> Starting from `emacs -Q', do M-x pixel-scroll-mode RET, then configure
> it as follows:
>
>     (setq pixel-dead-time 0)
>     (setq pixel-resolution-fine-flag 1)
>     (setq garbage-collection-messages t)
>
> Then scroll the display with the mouse wheel.  It will garbage collect
> like crazy, leading to a great deal of stuttering (in emacs-28 as well).
>
> I want to reuse most of the code in pixel-scroll.el for XInput2 pixel
> scrolling, but this is holding me back, as the excessive garbage
> collection makes it completely unusable.

This was almost a year ago, and I think you've fixed a bunch of things
in this area meanwhile, if I remember correctly?  Is this bug report
still relevant?  (I haven't tried to reproduce the problem myself.)

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

From: Po Lu <luangruo <at> yahoo.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 51886 <at> debbugs.gnu.org
Subject: Re: bug#51886: 29.0.50; pixel-scroll-mode garbage collects like crazy
Date: Wed, 21 Sep 2022 10:09:13 +0800

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

> This was almost a year ago, and I think you've fixed a bunch of things
> in this area meanwhile, if I remember correctly?  Is this bug report
> still relevant?  (I haven't tried to reproduce the problem myself.)

pixel-scroll-mode is still buggy and generates an incredible amount of
garbage.  However, pixel-scroll-precision-mode was eventually written to
use its own code, without touching the rest of the code in
pixel-scroll.el, so this bug report is not as relevant as it used to be.

I'm curious as to whether or not there are people still using the old
pixel-scroll-mode, especially since pixel-scroll-precision-mode should
now work "out of the box" with wheel mice on X.

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

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Po Lu <luangruo <at> yahoo.com>, Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 51886 <at> debbugs.gnu.org
Subject: Re: bug#51886: 29.0.50; pixel-scroll-mode garbage collects like crazy
Date: Tue, 20 Sep 2022 23:37:53 -0700

Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs <at> gnu.org> writes:

> pixel-scroll-mode is still buggy and generates an incredible amount of
> garbage.  However, pixel-scroll-precision-mode was eventually written to
> use its own code, without touching the rest of the code in
> pixel-scroll.el, so this bug report is not as relevant as it used to be.

Is `pixel-scroll-precision-mode' supposed to be a drop-in replacement
for `pixel-scroll-mode'?  If yes, how close is it?

> I'm curious as to whether or not there are people still using the old
> pixel-scroll-mode, especially since pixel-scroll-precision-mode should
> now work "out of the box" with wheel mice on X.

With `pixel-scroll-mode', I can see that when I scroll slowly, scrolling
behaves more like it would in Firefox (i.e., smooth rather than not
choppy).

With `pixel-scroll-precision-mode', I'm not sure I can spot any
difference with or without it enabled, when scrolling with the mouse
wheel.

I just found `pixel-scroll-precision-interpolate-page', which makes it
more attractive for me to use.  Is there a way to make it scroll faster
though?  If not, could we add such an option?

BTW, why isn't there a pixel-scroll defgroup under the scroll group
instead?  I tried `M-x customize-group RET pixel TAB' but couldn't find
anything relevant.

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

From: Po Lu <luangruo <at> yahoo.com>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 51886 <at> debbugs.gnu.org
Subject: Re: bug#51886: 29.0.50; pixel-scroll-mode garbage collects like crazy
Date: Wed, 21 Sep 2022 15:15:10 +0800

Stefan Kangas <stefankangas <at> gmail.com> writes:

> Is `pixel-scroll-precision-mode' supposed to be a drop-in replacement
> for `pixel-scroll-mode'?  If yes, how close is it?

It should be a complete drop-in replacement, except for people who
really, really, like the old line-based "pixel" scrolling.  And I think
it's already there, sans bugs like what you are experiencing.

> With `pixel-scroll-mode', I can see that when I scroll slowly, scrolling
> behaves more like it would in Firefox (i.e., smooth rather than not
> choppy).
>
> With `pixel-scroll-precision-mode', I'm not sure I can spot any
> difference with or without it enabled, when scrolling with the mouse
> wheel.

Hmm, that sounds like a bug.  Could you please run the following code:

  (progn (read-event) (message "Device: %s" last-event-device))

and show what is printed once you turn your mouse wheel?

> I just found `pixel-scroll-precision-interpolate-page', which makes it
> more attractive for me to use.  Is there a way to make it scroll faster
> though?  If not, could we add such an option?

Try playing with pixel-scroll-precision-interpolation-total-time, and
pixel-scroll-precision-interpolation-between-scroll.  I agree those
options should be easier to use, and I will work on them at some point.

> BTW, why isn't there a pixel-scroll defgroup under the scroll group
> instead?  I tried `M-x customize-group RET pixel TAB' but couldn't find
> anything relevant.

Those options are under the "mouse" group, but I won't object to moving
them into their own group.

Thanks.

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

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Po Lu <luangruo <at> yahoo.com>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 51886 <at> debbugs.gnu.org
Subject: Re: bug#51886: 29.0.50; pixel-scroll-mode garbage collects like crazy
Date: Wed, 21 Sep 2022 01:55:24 -0700

Po Lu <luangruo <at> yahoo.com> writes:

> It should be a complete drop-in replacement, except for people who
> really, really, like the old line-based "pixel" scrolling.  And I think
> it's already there, sans bugs like what you are experiencing.

It still isn't clear to me why it doesn't just replace the old mode (if
we need to keep it, why not name it `pixel-scroll-old-mode'?).  Maybe
I'm missing something.

> Hmm, that sounds like a bug.  Could you please run the following code:
>
>   (progn (read-event) (message "Device: %s" last-event-device))
>
> and show what is printed once you turn your mouse wheel?

"Device: A..... G3"

BTW, is it expected that it ignores the first scroll on the mouse wheel,
and prints the above only on the second?  (Tested in both directions.)

> Try playing with pixel-scroll-precision-interpolation-total-time, and
> pixel-scroll-precision-interpolation-between-scroll.  I agree those
> options should be easier to use, and I will work on them at some point.

Thanks, that will be appreciated.

>> BTW, why isn't there a pixel-scroll defgroup under the scroll group
>> instead?  I tried `M-x customize-group RET pixel TAB' but couldn't find
>> anything relevant.
>
> Those options are under the "mouse" group, but I won't object to moving
> them into their own group.

I created a new bug report for that.

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

From: Po Lu <luangruo <at> yahoo.com>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 51886 <at> debbugs.gnu.org
Subject: Re: bug#51886: 29.0.50; pixel-scroll-mode garbage collects like crazy
Date: Wed, 21 Sep 2022 18:50:31 +0800

Stefan Kangas <stefankangas <at> gmail.com> writes:

> It still isn't clear to me why it doesn't just replace the old mode (if
> we need to keep it, why not name it `pixel-scroll-old-mode'?).  Maybe
> I'm missing something.

I think Eli preferred to keep the old mode.

> "Device: A..... G3"

Did you censor some information with the periods, or is that literally
what was printed?

> BTW, is it expected that it ignores the first scroll on the mouse wheel,
> and prints the above only on the second?  (Tested in both directions.)

Yes, that's a limitation of the X API.  Emacs needs to swallow an
initial event in order to obtain the "initial" value of the scroll
wheel, before it can obtain scroll deltas by comparing it with the
absolute values of subsequent events.

Thanks.

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

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Po Lu <luangruo <at> yahoo.com>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 51886 <at> debbugs.gnu.org
Subject: Re: bug#51886: 29.0.50; pixel-scroll-mode garbage collects like crazy
Date: Wed, 10 Jan 2024 02:59:32 -0800

Po Lu <luangruo <at> yahoo.com> writes:

>> "Device: A..... G3"
>
> Did you censor some information with the periods, or is that literally
> what was printed?

(Sorry for the very late reply here.)

No censoring, this is what was literally printed.

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

From: Po Lu <luangruo <at> yahoo.com>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 51886 <at> debbugs.gnu.org
Subject: Re: bug#51886: 29.0.50; pixel-scroll-mode garbage collects like crazy
Date: Wed, 10 Jan 2024 19:34:24 +0800

Stefan Kangas <stefankangas <at> gmail.com> writes:

> (Sorry for the very late reply here.)
>
> No censoring, this is what was literally printed.

Hmm, in that case there's nothing from which Emacs can identify it as a
mouse.  I suggest configuring pixel-scroll-precision-large-scroll-height
to a suitable value, as we recommend users do in similar situations.

As for the reason this is not set by default, there is no
one-size-fits-all value for the variable that is guaranteed not to
classify events produced by touchpads as mouse events and lead to
Emacs's interpolating them erroneously, which would upset most users,
who enable pixel-scroll-precision-mode for touchpads only.

Previous Next

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