sxyazi / yazi

💥 Blazing fast terminal file manager written in Rust, based on async I/O.
https://yazi-rs.github.io
MIT License
15.59k stars 355 forks source link

Option to specify scrollwheel distance #954

Closed Zeioth closed 5 months ago

Zeioth commented 5 months ago

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?

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 commented 5 months ago

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

mikavilpas commented 5 months ago

We discussed mouse support in https://github.com/mikavilpas/yazi.nvim/issues/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 commented 5 months ago

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 commented 5 months ago

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:

https://github.com/sxyazi/yazi/assets/300791/0bbf6b17-8b6f-40fb-9e41-51928a16fd99

sxyazi commented 5 months ago

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:

https://github.com/sxyazi/yazi/blob/2febbee59555178f9d00315b3f1bba81b0af3165/yazi-plugin/preset/components/current.lua#L1-L3

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 commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

@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 commented 5 months ago

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 commented 5 months ago

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

github-actions[bot] commented 4 months ago

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 commented 4 months ago

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 https://github.com/sxyazi/yazi/pull/1038! 🎉