Option to specify scrollwheel distance

[Zeioth]

Please describe the problem you're trying to solve

By default, using the scrollwheel, move 3 positions on the manager list.

Would you be willing to contribute this feature?

• Yes, I'll give it a shot

Describe the solution you'd like

It would be nice having an option to specify how many positions the scroll move.

Additional context

No response

[sxyazi]

I didn't quite get your meaning - Yazi currently doesn't support any mouse operations.

[mikavilpas]

We discussed mouse support in mikavilpas/yazi.nvim#49 and added basic/hacky support (when embedded in neovim). It seems at least wezterm forwards scroll events to yazi and they do work on a basic level.

[sxyazi]

It looks like WezTerm converted the user's mouse scroll into <Up> and <Down> keys. When I add:

{ on = [ "<Up>" ],   run = "noop" },
{ on = [ "<Down>" ], run = "noop" },

to keymap.toml, scrolling stops working.

So I don't think there's something Yazi can do, as this is not a real mouse scroll event, Yazi just receives the atomic events <Up> and <Down> from the terminal.

[mikavilpas]

Interesting. I actually played around the code a bit last night, and I was happy to see that the Crossterm backend has support for all kinds of mouse events.

I started implementing support for click events, but I think scroll events would be much easier. Do you think this could be a useful feature?

To learn about the events and play around with them, there's a nice example that you can run in your terminal at https://github.com/crossterm-rs/crossterm/tree/master/examples (event-stream-tokio). It was able to recognize at least the following for me:

mouse-events.mov

[sxyazi]

I agree that mouse support would be a useful feature, and many users have requested it.

However, implementing it is more complex than imagined because most of Yazi's UI can be rewritten in Lua, and relies on this to implement dual-pane/tree-view in the future. So Yazi itself does not know what area the user is clicking/scrolling on, meaning mouse events must also be handled in Lua.

Perhaps it will eventually become a separate mouse.yazi plugin. My current idea is to add a new click and scroll method for each component (such as Current, Parent, Preview, etc.), which would be processed in parallel with the render() method.

After the user performs a mouse operation, the event would be forwarded to the corresponding component based on the mouse coordinates and the component area they claimed like this:

yazi/yazi-plugin/preset/components/current.lua

Lines 1 to 3 in 2febbee

	Current = {
	area = ui.Rect.default,
	}

However, this would be a complex task, and I currently don't have enough time to support it. But I would love to see someone pick it up.

[Gajus84]

It looks like WezTerm converted the user's mouse scroll into <Up> and <Down> keys. When I add:

{ on = [ "<Up>" ],   run = "noop" },
{ on = [ "<Down>" ], run = "noop" },

to keymap.toml, scrolling stops working.

So I don't think there's something Yazi can do, as this is not a real mouse scroll event, Yazi just receives the atomic events <Up> and <Down> from the terminal.

It's the same on Foot, Alacritty and Kitty. So maybe that's how terminals solve their own backscrolling features?

BTW, just for reference: I just tested mousewheel scrolling with joshuto and ranger and both do not have this "jump 3 positions behavior". On them it's line by line.

[sxyazi]

I believe this is a fallback behavior when the terminal detects that the CLI program hasn't requested mouse support, while both Ranger and Joshuto have requested it from the terminal, but accordingly, the CLI program needs to handle the mouse events.

[mikavilpas]

@Zeioth you can work around this and kind of get what you are looking for by setting this in keymap.toml in the[manager] section:

diff --git a/.config/yazi/keymap.toml b/.config/yazi/keymap.toml
index 05f4ea7..f18e425 100644
--- a/.config/yazi/keymap.toml
+++ b/.config/yazi/keymap.toml
@@ -106,10 +106,10 @@ keymap = [
 
   { on = [
     "<Up>",
-  ], run = "arrow -1", desc = "Move cursor up" },
+  ], run = "arrow -3", desc = "Move cursor up" },
   { on = [
     "<Down>",
-  ], run = "arrow 1", desc = "Move cursor down" },
+  ], run = "arrow 3", desc = "Move cursor down" },
   { on = [
     "<Left>",
   ], run = "noop" },

[Zeioth]

You are correct it's my terminal emulating the scroll. I was able to change it on foot terminal adding this to ~/.config/foot/foot.ini

[scrollback]
lines=10000
multiplier=1.0
# instead of
multiplier=3.0

Still, I can confirm ranger allow both, clicking items on the manager, and has an option to configure the scroll distance. It's not super critical because one can just filter, but still something nice.

[sxyazi]

Glad to see the problem solved. Closing as invalid since this is a terminal behavior

[github-actions]

I'm going to lock this issue because it has been closed for 30 days. ⏳
This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

[sxyazi]

I agree that mouse support would be a useful feature, and many users have requested it.

This feature has now been implemented by @qsdrqs in #1038! 🎉