Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Option to specify scrollwheel distance #954

Closed
1 task
Zeioth opened this issue Apr 25, 2024 · 12 comments
Closed
1 task

Option to specify scrollwheel distance #954

Zeioth opened this issue Apr 25, 2024 · 12 comments
Labels
invalid This doesn't seem right

Comments

@Zeioth
Copy link

Zeioth commented Apr 25, 2024

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

@Zeioth Zeioth added the feature New feature request label Apr 25, 2024
@sxyazi
Copy link
Owner

sxyazi commented Apr 26, 2024

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

@sxyazi sxyazi added the waiting on op Waiting for more information from the original poster label Apr 26, 2024
@mikavilpas
Copy link
Contributor

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
Copy link
Owner

sxyazi commented Apr 26, 2024

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
Copy link
Contributor

mikavilpas commented Apr 26, 2024

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
Copy link
Owner

sxyazi commented Apr 26, 2024

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:

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
Copy link

Gajus84 commented Apr 26, 2024

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
Copy link
Owner

sxyazi commented Apr 26, 2024

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
Copy link
Contributor

mikavilpas commented Apr 26, 2024

@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
Copy link
Author

Zeioth commented Apr 29, 2024

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.

@github-actions github-actions bot removed the waiting on op Waiting for more information from the original poster label Apr 29, 2024
@sxyazi
Copy link
Owner

sxyazi commented Apr 30, 2024

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

@sxyazi sxyazi closed this as not planned Won't fix, can't repro, duplicate, stale Apr 30, 2024
@sxyazi sxyazi added invalid This doesn't seem right and removed feature New feature request labels Apr 30, 2024
Copy link

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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 31, 2024
@sxyazi
Copy link
Owner

sxyazi commented Jun 3, 2024

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! 🎉

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
invalid This doesn't seem right
Projects
None yet
Development

No branches or pull requests

4 participants