io12 / good-scroll.el Goto Github PK

Much faster than pixel-scroll-mode!!
This alone is really good.

Occasional breaks appear when scrolling.
It seems to appear more when scrolling upwards.

The options related to scrolling were not modified and used as defaults.
mouse-wheel-scroll-amount, mouse-wheel-progressive-speed, scroll-step...

I'd like to share some user experiences over the past few days of heavy coding on Emacs using this package: I realized that the scrolling performance seems to be affected by the major-mode. Specifically, programming modes (at least to my investigation) generally scroll with suboptimal performance in comparison to non-programming modes like text-mode or org-mode. I've tested it using the exact same buffer content, simply switching the modes with M-x c++mode or M-x text-mode etc.. Since I have several hooks added to programming modes, I initially wondered if it was something like "display-line-numbers-mode" or "font-lock-mode" that was causing the suboptimal performance. However, I manually disabled those minor modes to have a clean comparison and see no effect.

P.s. Suboptimal scrolling performance includes a lag between scrolling the mouse wheel and the actual scroll of the buffer. Also, sometimes the scrolling stops earlier than it's supposed to.
P.p.s. I really appreciate your effort! To the extent that I even gave this package a shoutout on Reddit haha

Describe the bug
When running good-scroll-mode together with display-line-numbers-mode, the CPU usage goes up to ~10% to 15% on my 2.6GHz CPU using Emacs 28.1 with native-comp. The window with the line numbers has to be active to see the behaviour. If I switch to another window after C-x 2 the CPU usage goes down. Giving focus to the window with line numbers: higher CPU again.

To Reproduce
Steps to reproduce the behavior:

1. use the following ready-to-start (uses use-package) .emacs I prepared:

(require 'package)
(setq package-enable-at-startup nil)
(add-to-list 'package-archives '("melpa" . "https://melpa.org/packages/"))
(if (string-equal system-type "gnu/linux")
    (setq gnutls-algorithm-priority "NORMAL:-VERS-TLS1.3")) ; make default https elpa usable again
(package-initialize)
(unless (package-installed-p 'use-package)
  (package-refresh-contents)
  (package-install 'use-package))

;; configure use-package
(eval-when-compile
  (require 'use-package)
  (setq use-package-compute-statistics t)
  (require 'use-package-ensure)
  (setq use-package-always-ensure t))


(use-package good-scroll
  :config (good-scroll-mode 1))

(global-display-line-numbers-mode)

2. open some text or source code file
3. watch the CPU emacs consumes, should be quite high (for an idle text editor)
4. disable display-line-numbers-mode
5. watch the CPU emacs consumes, should be very low

Expected behavior
Low CPU usage with good-scroll and display-line-numbers-mode.

Videos
N/A

Version and environment

• OS: Debian 11
• Emacs version: GNU Emacs 28.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.24, cairo version 1.16.0) of 2022-08-20, modified by Debian

Additional context
Uses native-comp, but I'm not sure if that matters.

It's better to animate scrolling with a Bezier curve than linearly interpolating the position. Ideally, the algorithm should be configurable.

Scrolling over a wrapped line jumps instead of scrolling smoothly over it.

Scrolling can jump backwards when scrolling down when the point is at the bottom of the window and an image is at the top.

This is hands-down the best smooth scrolling implementation -- it's almost perfect! There's just one minor complaint:

When the user is done with a smooth scroll, sometimes it stops at half the line height, meaning that the visible top line and bottom line of the buffer can appear to be cut off by half. Which is absolutely fine, except that when the user starts typing or starts moving around with the arrow keys, Emacs will correct the buffer display and adjust such that the top line and bottom line are wholly visible. This results in a jitter every time good-scroll stops at the fraction of a line height and the user starts typing with the keyboard.

Please let me know if I explained it all right. It's kinda hard to put into words.

Nevertheless, this is really a great implementation, I wish more people discover it.

Describe the bug
When the window's vscroll is nonzero, so the top is scrolled partway through a line, some cursor movement commands can make the cursor overlap the top of the window.

To Reproduce
Steps to reproduce the behavior:

1. Open a window to a buffer with lots of text.
2. Scroll such that (window-vscroll nil t) returns nonzero.
3. Call (vertical-motion -1) until the cursor overlaps the top of the window.

Expected behavior
The vscroll should reset to zero when the cursor overlaps the top of the window, to prevent the overlap.

Videos

Version and environment

• OS: GNU+Linux
• Emacs version 27.2

Additional context
I think the only way to fix this is to add a function to post-command-hook that has the logic for handling this.

https://www.emacswiki.org/emacs/SmoothScrolling

Describe the bug
When two windows are in the same frame and the cursor is in the top window and the mouse is hovering over the bottom window, scrolling does nothing. Switching focus to the bottom window by clicking instantly jumps the scroll by the expected amount.

To Reproduce
Steps to reproduce the behavior:

1. Open an Emacs frame.
2. Create two windows in the frame.
3. Open a file in each frame.
4. Click the first frame to focus it.
5. Hover the mouse above the second frame (but don't click).
6. Scroll down.
7. Observe how nothing happens.

Expected behavior
The expected behavior is for the unfocused window to scroll just as if it were focused.

Version and environment

• OS: GNU+Linux
• Emacs version: 27.2

Additional context
This bug happens because good-scroll uses (selected-window) to figure out which window to scroll, which returns the focused window, not the one the mouse is hovering over.

Describe the bug
If the scroll builds up speed (such as by scrolling the text up at the bottom of the buffer), the good-scroll-destination keeps increasing, so the next time the user scrolls it will be too far.

To Reproduce
Steps to reproduce the behavior:

1. Call good-scroll-up until the bottom of the buffer is reached
2. Call good-scroll-up a few more times
3. Move to the beginning of the buffer without using good-scroll (such as by pressing g g in evil-mode)
4. Call good-scroll-up
5. Observe how it scrolled too far

Expected behavior
It should scroll the same amount as if good-scroll-destination were zero.

Version and environment

• OS: GNU+Linux
• Emacs version 27.2

Additional context

This issue shouldn't be too hard to fix.

Using wheel with good-scroll and linum-mode the line numbers sometimes disappear. But click left mouse, the line numbers will appear.

Thanks a lot for this package, it makes Emacs feel so much better and modern.

One question I had was if there is a way to configure something, so it scrolls a little faster?

When I scroll in other apps, the same amount of movement results in twice as much scrolling, whereas in Emacs with good-scroll it is scrolling only about half the rate, so I need to physically scroll more (or it seems scroll the same amount but faster) to get the same effect.

Thanks

can good-scroll.el enable for page-up and page-down action!

Describe the bug
Scrolling causes cursor to flicker

To Reproduce
Steps to reproduce the behavior:

1. Scroll to any direction
2. Cursor flickers

Expected behavior
Cursor doesn't flicker

Videos
I tried to record it several times, but for some reason I just can't capture the flicker in the video (or rather the flicker does not look as severe as it actually is), I'm guessing it has something to do with the framerate.

Version and environment

• OS: Windows 10 (MinGW-w64)
• Emacs version: 28.0.92

Additional context
I'm using evil-mode.

Scrolling up keeps jumping back to the cursor position in emacs ipython notebook, while scrolling down works very well and is super smooth across images (which I was trying to achieve). It seems like the cursor travels a few lines up when I scroll up and then gets stuck. I need to move the cursor to be able to scroll further up, so this breaks it for me unfortunately.

I would be very happy if this can be solved somehow, because it works super well on the down-scroll and makes it so much better to edit jupyter notebooks with plots.

There are potential conflicts between mwheel.el customization options and good-scroll. Removing the reliance might also improve performance.

Thanks a lot for this amazing plugin, i really enjoy it.
But line number will disappear when scroll up or down. Mouse click or other action can make it normal.
Though it is not even a bug, it just make me feel a bit uncomfortable. how can i fix it?

Describe the bug
I get an error when I press shift-tab to close the org-mode document

Error running timer ‘good-scroll--render’: (wrong-type-argument number-or-marker-p nil) [208 times]

As you can see, the error was executed 208 times

Version and environment

• OS: macOS
• Emacs version 28.1.4

Is your feature request related to a problem? Please describe.
I usually don't use the scroll wheel or page down/up keys to navigate emacs, I skip around by paragraph. This causes the window to snap to the new position, but I would prefer if it scrolled smoothly instead of snapping, like this package does when scrolling with the scroll wheel or page down/up keys.

Describe the solution you'd like
When the window snaps to the new position, it could be snapped back to where it was (or as far back as possible while keeping the cursor inside the window), and then running the regular good-scroll movement logic to move smoothly to where the window was originally snapped.

Describe alternatives you've considered
Entirely reimplementing the window snapping that happens when moving around with the cursor, so that it uses the good-scroll scrolling functionality straight away. However, this seems like it would require a lot of replacing functionality that isn't needed by the solution above.

Additional context
This feature feels like it would be better off being its own package, but on the other hand, good-scroll has scrolling logic that I think would be beneficial to share with this feature. In any case, I've implement a sort-of-working proof of concept in my fork, but it still requires some tweaking, and might be overall relatively misguided, as it's the first elisp thing I've written. The actual functionality also looks a little weird when scrolling a lot (out-pacing the smooth scrolling), but I think that's a necessary side-effect of the solution I came up with.

And finally, thank you for writing this package, it's made my daily emacs use a much nicer experience!

Scroll-up could mean either the page moving up or the viewport moving up. Create an issue template with a standard definition so it doesn't get too confusing.

I'm not an expert emacs user, so I'm sorry if this has a very obvious solution. But How can I replace evil-scroll-down that scrolls half a page with good-scroll-down. As far as I can tell, good-scroll-down doesn't have param for how many lines to scroll. My question is; is that possible to replace evil's scroll function, if so how? BTW, Thanks for the package, it works great for mouse scrolling for me.

As titled: When the cursor is placed on the first line of the file and the user wishes to scroll down, the frame appears to be stuck and struggles to scroll more than a few pixels.

This happens sometimes too when the cursor is positioned on the first line of the "visible frame" (not necessarily the first line of the file).

#6 and #7 are possibly related issues, but I'm not quite sure.

Enabling good-scroll-mode breaks moving the cursor left or right in evil-mode, either by the hl or arrow keys. A message is given of: Args out of range: 1, 3642. This doesn't prevent cursor movement with the arrow-keys in insert-mode.

Disabling good-scroll-mode again fixes the issue.

I'm running Doom on gccemacs.

hi, first, i'm happy to say good scroll now works rly well for me when in the past it didn't, well done.

i have just been trying to use it in pdf-view-mode, and it works (which is a real pleasure for reading!), but when i try to select some text to create an annotation, the scroll position reverts to what it was before any smooth mouse good scrolling was done.

i noticed it doesn't do this if i e.g. hit down arrow to scroll by one line after some smooth mouse good scrolling.

(not sure if this is an issue for good scroll or pdf-tools, or maybe there's already a simple user way to solve this...)