Tig: [Feature request] Mouse support

[losingkeys]

It'd be nice to be able to scroll/click like vim with set mouse=a

[michaelbarlow7]

I'd like this as well. No idea how hard this would be to implement, but maybe I'll have a go...

[losingkeys]

It might be worth looking at the vim/tmux source too.

On Dec 10, 2013, at 5:34 PM, Michael Barlow [email protected] wrote:

I'd like this as well. No idea how hard this would be to implemen, but maybe I'll have a go...

—
Reply to this email directly or view it on GitHub.

[michaelbarlow7]

Yeah for sure. I imagine this would come in handy as well:
http://www.tldp.org/HOWTO/NCURSES-Programming-HOWTO/mouse.html

[jonas]

Yes, using mouse events provided by Ncurses would be the best. However it
looks like it is not enabled by default in all package managers.

[michaelbarlow7]

Currently having a go at implementing this on my fork:

https://github.com/michaelbarlow7/tig

[michaelbarlow7]

Just noticed your comment Jonas - what do you mean by it not being enabled in package managers?

I've managed to get some stuff up and running, mostly just clicking on commits. Clicking on something that's already selected will show a diff (as if you had pressed enter).

[michaelbarlow7]

Ok, so I've been hacking away at this today, and managed to get some mouse support going :).

Right now I've implemented the following:

• Clicking on a line will highlight that line if it hasn't been highlighted already
• If it is already highlighted, it will 'open' that line (as if you had pressed enter, so usually a diff or something).
• If you have two views open, it will select the view that you click on.
• Scrolling with the scroll-wheel will scroll a certain amount (3 lines at a time by default).
• Mouse-support can be disabled via .tigrc via the "set mouse" boolean option.
• The scroll-wheel distance can be specified as an integer via the "set scroll-wheel-lines" option.

I won't initiate the pull-request yet, since I want to test it out a bit first, and I'm sure there will be suggestions/things I've missed. I know the scrolling seems a bit jerkier than it should be, so I might be missing some scroll events here. Plus, I might have implemented it differently to what you guys had in mind.

in any case, have a play and let me know what you think:
https://github.com/michaelbarlow7/tig

[losingkeys]

Beautiful! I haven't tested toggling the options, but other than that I've only noticed one possible issue:
in version 1.2.1.1 (and I think earlier versions), if you have a diff open, and you hit down a bunch, it'll change which diff is opened based on which line (in the log) is selected. When scrolling with the mouse it doesn't do that. That said, it's awesome how you can scroll the diff and the top separately. Cheers!

[michaelbarlow7]

Glad you like it! I've just tested it out on OS X, scrolling seems smoother than on my Linux setup. Not totally sure why, maybe it's something to do with my mouse?

I think I see what you mean re: changing the diff when pressing up/down. I guess it's debatable what the behaviour should be here. If you press TAB to switch views, and then go down, it doesn't change the diff until you press enter on a commit. I can totally see the case for having it change the diff straight away though.

Another thing I realised was that I can no longer select commits to copy and paste them, which is kind of annoying, but I guess necessary. I think I should at least disable clicking on the title display bars.

[losingkeys]

Hmm, I've noticed in other curses-based programs that support the mouse I have to hole option on osx or shift on Linux to select text via the terminal.

With the mouse you shouldn't need to hit tab to switch views, right? You can just hover over either pane and scroll there instead. That said, you should still be able to use tab and the keyboard alongside the mouse.

Also I've noticed in iterm scrolling different vim splits always scrolls the active one (much like trying to scroll unfocused windows in windows). However in urxvt, I can scroll any split, whether the cursor is on it or not, so scrolling either pane might be a bug in iterm, because it WFM :)

On Dec 15, 2013, at 6:25 PM, Michael Barlow [email protected] wrote:

Glad you like it! I've just tested it out on OS X, scrolling seems smoother than on my Linux setup. Not totally sure why, maybe it's something to do with my mouse?

I think I see what you mean re: changing the diff when pressing up/down. I guess it's debatable what the behaviour should be here. If you press TAB to switch views, and then go down, it doesn't change the diff until you press enter on a commit. I can totally see the case for having it change the diff straight away though.

Another thing I realised was that I can no longer select commits to copy and paste them, which is kind of annoying, but I guess necessary. I think I should at least disable clicking on the title display bars.

—
Reply to this email directly or view it on GitHub.

[losingkeys]

I spoke too soon. What I was trying to say is that it would be cool to be able to scroll the log view and the diff view by hovering over them with the mouse and scrolling, regardless of which one is active (which one would move if you used the keyboard).

I thought this branch supported that, but I think I didn't spend enough time testing it. I don't think iterm supports this (it doesn't in vim), but urxvt does.

Thanks for all the work so far and let me know if you want me to test this on a specific os/terminal.

[michaelbarlow7]

Hey Joshua, you're right, this branch doesn't currently support being able to scroll certain views by hovering over the view and then scrolling. I've been using it for a while and I think it'd be worth adding this.
So I think I'll add the following:

• When there are two views open (e.g. a main view and a diff view), selecting a line in the main view will change what is shown in the secondary view.
• Scrolling with the mouse-wheel will scroll whichever view the cursor is hovering over, otherwise it will scroll whichever view is currently selected
  
  
  
  • I'm not sure if scrolling a particular view should also select that view. What do you guys think? Will play around with it and see what happens.
  
  
• Clicking the display bar (i.e. the bar that shows the current commit hash in the main view) shouldn't register as a click (it currently scrolls the view).

Also, you're right - holding down the option-key will allow me to select bits of text to copy. Good to know!

[michaelbarlow7]

Ok, so I've just implemented the above things in my fork. Have a play around and see how it feels. I think it might be close to being good enough for a pull-request.

https://github.com/michaelbarlow7/tig

I've made it so scrolling a view will select that view, but it doesn't really make a huge difference either way I don't think.

[losingkeys]

Very slick :smile:. If I had to choose I'd say leave focus where it was, because in most OSs you can scroll one window while leaving the others focused. In some you can do focus-follows-mouse, so maybe that's important enough to warrant an option.

All in all, good work!

[michaelbarlow7]

Thanks @joshuarh . Yeah, I totally get your point re: window selection in OSs, but I decided to leave it as is, since it just works out to be simpler (at least, in the way I've already coded it), since it handles all mouse events consistently (view selection is handled the same way whether it's a mouse click, or a scroll wheel up/down event).
Anyway, thanks heaps for the feedback, I've just submitted the pull-request :).

[losingkeys]

Cheers!

On Dec 28, 2013, at 5:28 PM, Michael Barlow [email protected] wrote:

Thanks @joshuarh . Yeah, I totally get your point re: window selection in OSs, but I decided to leave it as is, since it just works out to be simpler (at least, in the way I've already coded it), since it handles all mouse events consistently (view selection is handled the same way whether it's a mouse click, or a scroll wheel up/down event).
Anyway, thanks heaps for the feedback, I've just submitted the pull-request :).

—
Reply to this email directly or view it on GitHub.

[jonas]

So @michaelbarlow7 excellent patch is merged, but you have to add the following line to ~/.tigrc

set mouse = true

since mouse support is disabled by default to not get in the way of text selection.

[jeremyckahn]

Thanks for adding this feature. It looks like the latest version available to Homebrew is 1.2.1. Can this be updated so that I can get this feature on OS X?

[bkudria]

+1 on releasing this and other great stuff since 1.2.1

[jonas]

I'm planning to release version 2.0 on April 10th ... That day tig will be
8 years in the making.
On Apr 1, 2014 2:12 PM, "Benjamin Kudria" [email protected] wrote:

+1 on releasing this and other great stuff since 1.2.1

—
Reply to this email directly or view it on GitHubhttps://github.com/jonas/tig/issues/157#issuecomment-39238938
.

[michaelbarlow7]

@jeremyckahn You can get this feature via homebrew by installing the HEAD version (i.e. "brew install tig --HEAD"). You'll also need to enable it by adding "set mouse = yes" to ~/.tigrc.

[jeremyckahn]

This is so great. Thanks, all! And congrats, @jonas! Tig is an amazing tool.

[bkudria]

+1 tig is amazing and mouse support is awesome!

[andrewmchen]

Just found this feature and holyshit is it a lifesaver. Scrolling through diffs with j/k or is so tedious. Only problem is that this feature isn't visible enough.