Collecting User Information & Experiences

[jdtsmith]

As I learned writing indent-bars, it can be challenging to write cross-platform graphically intensive package in Emacs, because individual ports, builds, and systems actually vary widely in capabilities. What is documented in the manual to be a basic feature may work only on some builds. When you count all the various graphical backends and options, the number of build "flavors" is in the many dozens. And in ultra-scroll, we also add the complexity of the underlying input hardware (mouse or trackpad).

I am unable to test most combinations of systems, OS, and hardware, so rely on user experience. If you have tried ultra-scroll and had a positive or negative experience, please help out by mentioning the following:

User Input Survey

1. What system are you on (paste results of (emacs-version))?
2. Any related build flags (e.g. --xinput2 for Linux people)?
3. What does M-x ultra-scroll-check report after you send events (e.g. "Normal scroll events")?
4. What input hardware did you try?
5. Any special configuration to your desktop system, window manager, etc. you need to configure?
6. Did ultra-scroll work for you?
7. Did it provide smooth scrolling?
8. Does it give you "momentum" scrolling? (i.e. continued scrolling after you lift your fingers)
9. Did it alleviate issues scrolling tall images?
10. Any other notes or comments?

Please keep it brief and don't discuss issues here (you can open a new issue). Just the facts. Thanks!

[jdtsmith]

I'll start:

emacs-mac + NS on MacOS 15.2, both working

1. GNU Emacs 29.4 (build 1, aarch64-apple-darwin24.2.0, Carbon Version 170 AppKit 2575.3) of 2025-01-07, and also GNU Emacs 29.4 (build 2, aarch64-apple-darwin24.2.0, NS appkit-2575.30 Version 15.2 (Build 24C101)) of 2024-12-23
2. None
3. Native Comp Detected, Normal pixel scroll data: -47.0 to -1.0 (-16.73 mean)
4. Logitech MX Master, a Cheap click USB-dongle mouse, MacBook trackpad.
5. No, smooth scrolling and momentum scrolling are built-in to MacOS. I used LogOptions+ to set the MXMaster scroll rate and enable smooth scroll (simulating a trackpad).
6. Yes, on all 3 devices.
7. Yes, scrolling is smooth.
8. Yes, momentum is provided by MacOS and works well.
9. Yes, tall images work fine.
10. Thanks (self) for ultra-scroll :) !

[idlip]

Hi, thanks for extending this for all builds.

Emacs-pgtk, Nixos

1. GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.43, cairo version 1.18.2)

2. Latest package (emacs-pgtk, 31.0.50) from emacs-overlay

3. Native Comp Detected

   • Trackpad: Normal pixel scroll data: 100.0 to 134.8 (105.00 mean)
   • Redragon Mouse:
     pixel-scroll-precision-mode nil: Normal pixel scroll data: 179.4 to 229.4 (196.77 mean)
     pixel-scroll-precision-mode t: WARNING, all pixel scroll values == 150.00 No real pixel scroll data stream?

4. Trackpad, redragon Mouse

5. No, I use niri wayland WM

6. Yes

7. Yes

8. Yes, I can observe this after recent commits

9. Can't wait for it to be up-streamed. Cheers ;)

[jdtsmith]

Thanks. In recent builds, ultra-scroll turns on pixel-scroll-precision-mode, so you shouldn't set that separately. Probably the real underlying difference is mwheel-coalesce-scroll-events being on in the "not working" case. Can you investigate?

[idlip]

Probably the real underlying difference is mwheel-coalesce-scroll-events being on in the "not working" case. Can you investigate?

That is nil only
Edit: This might be similar to #6 (since we use nixos, emacs-pgtk)

[jdtsmith]

Well, pixel-scroll-precision-mode in fact turns it on, so it can't be "only" nil...

[zonuexe]

Emacs 30.0.93(NS) + macOS 15.2

1. GNU Emacs 30.0.93 (build 1, aarch64-apple-darwin21.6.0, NS appkit-2113.65 Version 12.7.6 (Build 21H1320)) of 2024-12-20 (Emacs For Mac OS X's build)
2. None
3. Scroll your mouse wheel or track-pad slow then fast to generate 30 events
4. MacBook Pro (14", 2021) built-in trackpad
5. No
6. Yes, no problem.
7. Excellent, very comfortable.
8. Looks good
9. No errors. I am a pdf-tools user and I have not seen any negative effects.
10. Thank you for your great work!

[roshanshariff]

Emacs 29.4 (Lucid+X11) on Fedora 41

1. GNU Emacs 29.4 (build 1, x86_64-redhat-linux-gnu, X toolkit, cairo version 1.18.2, Xaw3d scroll bars) of 2025-01-03
2. --with-x-toolkit=lucid --with-xinput2
3. ** 30 scroll events detected in 2.52s (11.9 events/s) *** Normal pixel scroll data: 12.4 to 49.8 (13.28 mean)
4. Logitech MX Master 2S
5. Running on XWayland
6. Yes
7. Yes, including high-resolution mouse wheel events
8. No, but I don't expect momentum with mouse wheels
9. Not tested with images
10. My mouse supports a high resolution scroll wheel, which reports pixel-delta values as you rotate the wheel at a higher rate than once per detent

Emacs 29.4 (PGTK) on Fedora 41

1. GNU Emacs 29.4 (build 1, x86_64-redhat-linux-gnu, GTK+ Version 3.24.43, cairo version 1.18.2) of 2025-01-03
2. --with-pgtk
3. ** 30 scroll events detected in 5.04s (5.9 events/s) *** WARNING, all pixel scroll values == -100.00 No real pixel scroll data stream? ** (try again, or use pixel-scroll-precision instead)
4. Logitech MX Master 2S
5. Running on Wayland without X11
6. No
7. No
8. No
9. Not tested with images
10. It appears that GTK3 (which is used by Emacs PGTK) does not support high-resolution scroll events with mouse wheels, only trackpads. There in an unmerged PR to backport this feature from GTK4.

Emacs 29.4 (GTK+X11) on Fedora 41

1. GNU Emacs 29.4 (build 1, x86_64-redhat-linux-gnu, GTK+ Version 3.24.43, cairo version 1.18.2) of 2025-01-03
2. --with-x-toolkit=gtk3 --with-xinput2
3. ** 30 scroll events detected in 0.65s (45.9 events/s) *** Normal pixel scroll data: 4.4 to 17.7 (4.71 mean)
4. Logitech MX Master 2S
5. Running on XWayland
6. Yes
7. Yes, including high-resolution mouse wheel events
8. No momentum
9. Not tested with images
10. Unlike the PGTK version, the GTK+X11 version of Emacs uses XInput2 to get high-resolution mouse wheel events rather than relying on GTK alone.

NOTE: If you're trying to get some background on high-resolution mouse wheel support in Linux, this issue has links to the implementation status and some blog posts. It should work correctly in Chromium and GTK4+ apps, but not in GTK3 apps like Firefox.

[rdiaz02]

Emacs 30.0.93, Lucid + X11 on Debian

1. GNU Emacs 30.0.93 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.18.2, Xaw scroll bars) of 2024-12-26
2. --without-xaw3d --with-x-toolkit=lucid --with-xinput2

* Native Comp Detected

 ** 30 scroll events detected in 5.03s (6.0 events/s)
 *** Normal pixel scroll data: 64.1 to 128.2 (64.08 mean)

But that is variable. I repeated and now I get

** 30 scroll events detected in 19.99s (1.5 events/s)
 *** WARNING, all pixel scroll values == 48.81 No real pixel scroll data stream?
 ** (try again, or use pixel-scroll-precision instead)

Trackpad or mouse wheel, both can give the same warning and both can give the non-warning in the same Emacs frame. I can't see a pattern.

4. Microsoft USB Mouse, Dell Precision Laptop trackpad
5. No
6. Yes
7. Yes (though the mouse wheel I think is restricted to very noticeable discrete jumps, also in browsers and other programs)
8. Yes (from the trackpad; I think mouse wheel cannot provide momentum)
9. YES! I can comfortably scroll over tall images in org mode :-)
10. None.

Emacs 30.0.93, GTK + X11 on Debian

1. GNU Emacs 30.0.93 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.43, cairo version 1.18.2) of 2024-12-23
2. --without-xaw3d --with-x-toolkit=gtk3 --with-xinput2
3. As above, this is variable. Some times

** 30 scroll events detected in 8.22s (3.6 events/s)
 *** Normal pixel scroll data: 10.6 to 15.4 (14.72 mean)

and sometimes

** 30 scroll events detected in 9.85s (3.0 events/s)
 *** WARNING, all pixel scroll values == -95.41 No real pixel scroll data stream?
 ** (try again, or use pixel-scroll-precision instead)

Trackpad or mouse wheel, both can give the same warning and both can give the non-warning in the same Emacs frame. I can't see a pattern.
4. Microsoft USB Mouse, Dell Precision Laptop trackpad
5. No
6. Yes
7. Yes (though the mouse wheel I think is restricted to very noticeable discrete jumps, also in browsers and other programs)
8. Yes (from the trackpad; I think mouse wheel cannot provide momentum)
9. YES! I can comfortably scroll over tall images in org mode :-)
10. None.

[jdtsmith]

If your mouse gives fairly granular scroll events (at a fairly low rate too I noticed, my fastest mouse reaches 120 events/s), this could explain occasional "all events the same" warnings. Try accelerating your scroll during ultra-scroll-check. Maybe your hardware/system is "intermediate" in providing a slightly varying stream of pixel scroll info. Linux is truly the Wild West when it comes to input.

[pkryger]

emacs-mac 29.4 on macOS 15.2

1. GNU Emacs 29.4 (build 1, aarch64-apple-darwin24.0.0, Carbon Version 170 AppKit 2566)
2. Installed with: brew install emacs-mac --HEAD --wiht-natural-title-bar --with-native-compilation --with-xwidgets --with-librsvg, commit:
   7cc5e67629363d9e98f65e4e652f83bb4e0ee674
3. Native Comp Detected, Normal pixel scroll data: 1.0 to 48.0 (13.87 mean)
4. Built in trackpad on macBook Air M2
5. No special configuration
6. Yes, ultra-scroll does work
7. Yes, scrolling is smooth
8. Yes, I can see "momentum" scrolling
9. I haven't try images
10. Great package, can wait for upstream! I have
    show-paren-context-when-offscreen set to overlay. When I used to use
    ultra-scroll-mac (commit: 07fbe0d), and
    after a scroll first line was not fully visible the show paren overlay that
    displayed on it was not visible either. This has is happening less often on
    the most recent commit (64ad7be), as it
    seems to realign buffer when point changes line. Although, if you put a
    point in the line with the closing paren (just before it), and the opening
    paren is not visible, and then scroll such that first line is only
    partially visible, the overlay is not fully visible.
    This is what I get: , while expecting:

[okomestudio]

Emacs 30.0.93, PGTK on Debian 12

• GNU Emacs 30.0.93 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.38, cairo version 1.16.0)
• --with-pgtk --with-x-toolkit=gtk
• With Kensington SlimBlade Trackball (via USB): Native Comp Detected; all pixel scroll values == 150.00 No real pixel scroll data stream?; With HHKB Studio Pointing Stick (via USB): Native Comp Detected; all pixel scroll values == -150.00 No real pixel scroll data stream?
• (1) Kensington SlimBlade Trackball (2) HHKB Studio Pointing Stick
• No special configuration with KDE; using keyd (https://github.com/rvaiya/keyd) but only for key remapping
• When active, it improves the large image scrolling, but it seems to disable the pixel scroll precision natively offered by Emacs
• No; see the previous answer. When I disable ultra-scroll and re-activate pixel-scroll-precision-mode, it works again
• No; see the previous answer.
• Yes.
• Thanks for the package development effort. The glitch-y scrolling on large images is what has prevented me from using precision scrolling, so it would be nice if ultra-scroll worked in my setting. It doesn't seem to quite work fully yet.

[jdtsmith]

Thanks for the report. See compatibility.

Pixel-scroll-precision uses interpolation for devices/systems like yours that do not provide pixel scroll information. Looks like there are lots of other users with success on Linux; maybe see if you can find a solution?

[jdtsmith]

emacs-mac 29.4 on macOS 15.2

Can you open a separate issue for this?

`show-paren-context-when-offscreen` set to `overlay`.  When I used to use

`ultra-scroll-mac` (commit: 07fbe0d10ec0d68207cbe0675c139f31d2b4d516), and

after a scroll first line was not fully visible the show paren overlay that

displayed on it was not visible either. This has is happening less often on

the most recent commit (64ad7be02e11317576498dabb15c92cf31e2c04c), as it

seems to realign buffer when point changes line. Although, if you put a

point in the line with the closing paren (just before it), and the opening

paren is not visible, and then scroll such that first line is only

partially visible, the overlay is not fully visible.

This is what I get: <img width="215" alt="Screenshot 2025-01-15 at 16 58 54" src="https://github.com/user-attachments/assets/b47b1187-ec43-46b1-b5bc-aa5592cd2649" />, while expecting:  <img width="172" alt="Screenshot 2025-01-15 at 16 59 15" src="https://github.com/user-attachments/assets/82cbd07f-ec75-4d68-bca6-aebb9649377a" />

[okomestudio]

Pixel-scroll-precision uses interpolation for devices/systems like yours that do not provide pixel scroll information. Looks like there are lots of other users with success on Linux; maybe see if you can find a solution?

@jdtsmith My question would be: Does "working in Linux" here means that it is possible for me to find a way to activate ultra-scroll (so that I can get the benefit of the fix for tall images) while letting the pixel scrolling fully fall back to the builtin pixel-scroll? From the compatibility section of readme, that part wasn't entirely clear to me.

[jdtsmith]

If you mean let pixel-scroll-precision fake smooth scrolling via interpolation, but somehow also have ultra-scroll's ability to scroll past tall images: no, that's not an option. Three options:

1. Use pixel-scroll-precision to interpolate (fake) smooth scrolling for you.
2. Use ultra-scroll for good handling of images, but your scrolling will be line-by-line.
3. Update your system and (if needed) hardware to get the best of both worlds.

[pkryger]

emacs-mac 29.4 on macOS 15.2

Can you open a separate issue for this?

Opened: #20

[AjaiKN]

1. GNU Emacs 30.0.93 (build 2, aarch64-apple-darwin24.1.0, NS appkit-2575.20 Version 15.1.1 (Build 24B91))
   of 2025-01-10
2. None

* Native Comp Detected

** 30 scroll events detected in 1.24s (24.3 events/s)
*** Normal pixel scroll data: 0.0 to 132.0 (32.50 mean)

4. MacBook trackpad
5. None
6. Yes, very well!
7. Yes
8. Yes
9. I don't scroll tall images much, so I'm not sure
10. Thank you! I can't stress enough how much this package has improved my experience with Emacs. I used it with emacs-mac when it was called ultra-scroll-mac (and that was the primary reason I was using emacs-mac). Now that it no longer requires emacs-mac, I've switched to homebrew-emacs-plus.

[martianhi]

Emacs 31.0.50, Linux, Debian stable, xfce

1. GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.38, cairo version 1.16.0) of 2024-12-27
2. Nothing fancy (I forget exactly). Native comp is active.

 ** 30 scroll events detected in 0.73s (41.3 events/s)
 *** Normal pixel scroll data: 7.1 to 74.9 (35.55 mean)

4. Thinkpad trackpad. (USB mousewheel scrolling is also changed: it is less jumpy, but it isn't momentum/super-smooth pixel style, seems ok like that)
5. Not particularly
6. Yes
7. Yes
8. Yes
9. Yes
10. Apart from the issue i opened here, I also get a slightly funny jump sometimes when typing text after scrolling. I'll see if I can catch it again and work out if its an actual issue (or perhaps it's expected). Thanks for the project!

[jdtsmith]

Regarding the "funny small jump", that happens after you end a scroll with a non-zero vscroll, since line-move and friends reset it. Since many parts of emacs insist on vscroll=0, and smooth scrolling requires vscroll != 0, a jump has to happen sometime.

[martianhi]

ultra-scroll doesn't seem to me to work on embark buffers.

if i pull up an embark buffer, then try to mouse-wheel scroll or touch scroll it, the buffer disappears, so i can never view the action i'm searching for.

with mouse-wheeling, i get this error:

Debugger entered--Lisp error: (error "ultra-scroll must be bound to an event with parameters")
  command-execute(ultra-scroll)
  #<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_86>(:action ultra-scroll :quit t :orig-type command :orig-target "which-key-mode" :bounds nil :type command :target "which-key-mode")
  embark--run-around-action-hooks(ultra-scroll (:orig-type command :orig-target "which-key-mode" :bounds nil :type command :target "which-key-mode") t)
  #f(compiled-function () #<bytecode -0x7868151950852ce>)()
  apply(#f(compiled-function () #<bytecode -0x7868151950852ce>) nil)
  #f(compiled-function () #<bytecode -0x13d981aff1e29b6a>)()
  #f(compiled-function () #<bytecode -0x1d65c9154d3c3342>)()

which-key-mode is the M-x command i had called embark on.

[jdtsmith]

Hard to see with all your compiled functions there, but looks like an issue with embark accidentally wrapping the scroll event callbacks. Can you open an issue there and link here?

[slarkkent]

1. GNU Emacs 30.1 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.49, cairo version 1.18.4) Native Comp Detected
2. Output of system-configuration-features: ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG LCMS2 LIBOTF LIBSYSTEMD LIBXML2 M17N_FLT MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP X11 XDBE XIM XINPUT2 XPM GTK3 ZLIB
3. ** 30 scroll events detected in 5.35s (5.6 events/s)
   *** WARNING, all pixel scroll values == 122.51 No real pixel scroll data stream?
   ** (try again, or use pixel-scroll-precision instead)
4. Logitech G502 Hero USB
5. Hyprland on Wayland on Archlinux
6. No, unfortunately not
7. See 6.
8. See 6.
9. See 6.
10. This works here: https://def.lakaban.net/2023-03-05-high-quality-scrolling-emacs/ - but I am curious if and how much smoother your solution is. I would provide you more test data in case you need it. 👍

[jdtsmith]

That's a very low scroll rate. Did you scroll as fast as possible? My devices (MacBook Air trackpad, Logitech MX Master) generate from 60-120 events/s. Maybe your mouse has "uniform click at a time" mode (mine has a small button under the scroll wheel to switch to that)? Then again maybe it's just a driver issue. Do you get smooth scrolling in e.g. the browser?

[slarkkent]

In my previous test I scrolled really slowly.

This is as fast as I can without the scroll wheel "release":
== ultra-scroll Scroll Event Report ==

• GNU Emacs 30.1 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.49, cairo version 1.18.4)
• Native Comp Detected

** 30 scroll events detected in 0.59s (51.3 events/s)
*** Normal pixel scroll data: 117.2 to 119.8 (115.36 mean)

And this with the scroll wheel "release" button pressed (mouse wheel moving freely):
== ultra-scroll Scroll Event Report ==

• GNU Emacs 30.1 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.49, cairo version 1.18.4)
• Native Comp Detected

** 30 scroll events detected in 0.11s (268.3 events/s)
*** WARNING, all pixel scroll values == -117.21 No real pixel scroll data stream?
** (try again, or use pixel-scroll-precision instead)

[jdtsmith]

Who, >200 events/s, but all the same? Seems like a driver issue. The data are all very similar, so it seems your hardware can produce different scroll deltas, but the drivers cannot or do not. Definitely look into your drivers. Here's what my Logitech looks like:

* GNU Emacs 30.1.90 (build 30, aarch64-apple-darwin24.5.0, Carbon Version 170 AppKit 2575.6)
 of 2025-07-10
* Native Comp Detected

 ** 30 scroll events detected in 0.29s (102.5 events/s)
 *** Normal pixel scroll data: 1.0 to 74.0 (57.53 mean)

[slarkkent]

If it is a driver issue, them I'm wondering why pixel-scroll-precision-mode is working for me.
Is there an explanation why this could be the case? Also tried it on my macOS with the same Logitech Mouse and also couldn't get it to work.

[jdtsmith]

Transferred to issue #33.

[jdtsmith]

Closing in favor of Discussions.

[jdtsmith]

Feel free to post further updates here.