feat: Simple mouse interactions #422
Conversation
- Left clicking an item will move the cursor there - Left clicking the item already at the cursor will toggle the section - Right clicking an item will show it
|
On macOS, which has momentum scrolling, I think there is a bug in termwiz handling of these events. If I flick the trackpad, the view scrolls and then suddenly I get the "Remote" menu (shortcut key "M") appearing. Logging out the events you can see that the mouse event appears as keyboard input for no reason, with the "M" key being the only one with a binding. This doesn't happen when scrolling normally (i.e. without momentum): I don't think this is particularly serious (unless you bind reset hard to |
|
Sweeeet! Seems to occur sometimes on my Fedora/Alacritty/Tmux too. Would love to have this as a default, but it's a nice start even with the bug. |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #422 +/- ##
==========================================
+ Coverage 86.48% 86.50% +0.02%
==========================================
Files 71 71
Lines 7116 7314 +198
==========================================
+ Hits 6154 6327 +173
- Misses 962 987 +25 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Ugh, that's unfortunate. Is it possible to try out the HEAD of termwiz somehow to see if this has been fixed, or if I should report it?
Do you think I should change the default to be I wondered if implementing a workaround where seeing |
|
It didn’t occur to me before now that I could probably put the show/open logic into the left click logic, and just check if the item is expandable to figure out which to do. Might be a bit more intuitive? |
I pushed a commit to do this, it feels a lot more natural. I kept the right-click thing, so you can show files in the staged/unstaged for example. |
Termwiz will sometimes not handle mouse scroll events, and instead they are sent as key events of the escape sequence. This causes issues because it triggers the app bindings, which could be harmful to users.
|
I added a workaround for the Termwiz bug, it just ignores key events for the next 75ms (a totally arbitrary number that felt like "not too long and not too short") every time it encounters Maybe now enabling mouse support by default is okay? |
|
I added code to directly disable mouse reporting in unix terminals if I ended up having to directly write the escape sequences to the terminal, since Termwiz doesn't seem to expose anything to do this and will always enable mouse reporting if the terminal has the capability. |
|
If it works smoothly, then having it as default would be nice. I seemed to notice a problem though, it seems that if I move the mouse around over the terminal, my CPU will spike (albeit in debug mode: Moving the mouse slowly, no weirdness: Moving the mouse fast / big terminal window: Must be the same symptoms you experienced while scrolling. |
I’d be interested to see if the mouse stuff works better on crossterm, could I just make a temp branch and rebase on top of yours to try it out? I assume the event types and other small things will be broken since they’re currently termwiz events. |
|
I think I got the majority of it fixed, but I think trying it out is a good idea. Feel free to steal the one I started on. |
This avoids a lot of CPU usage for just moving the mouse around.
Looking at your log, these events are spaced a few ms apart and there are quite a few that happen over the space of just a few milliseconds, obviously almost none of these are going to impact the UI since there are no clicks. I pushed a commit to avoid calling |
|
@jonathanj I can actually reproduce this bug in master, by moving the mouse. |
|
Hooray, thanks! I’m looking forward to enjoying mouse support. |
Magit has mouse support via emacs builtin mouse support, one particularly useful aspect of this is being able to jump around instantly instead of needing to navigate in a fashion like "next line, next line, … next line", such as when staging individual lines or moving to a particular commit/stash.
After using the mouse for a bit, I felt like perhaps there could be a few simple actions:
I tried to use as much of what infrastructure was already there to support implementing this, but one thing I didn't do was make the mouse actions bindable. I looked at how this might be done, modifying the parser to accept
mouse1_click, etc. seems very straightforward, but all of the parser functions returnKeyCodeand it seems like adjusting that might be it's own whole PR.I added a config option
general.mouse_supportthat defaults tofalseto preserve the existing behaviour, although it could be argued that since the mouse input is captured it would be more intuitive if it did something. This doesn't disable mouse reporting, but just ignores the mouse events. I briefly looked at trying to disable mouse reporting in TermWiz, but my initial attempts didn't work. I think I would need to dig into the TermWiz source and CSI modes more to understand how to do this.There's definitely some trailblazing in here, and some less-than-stellar code, so please feel free to suggest improvements.