Mouse misbehavior in v0.3.1

[vphantom]

This may be related to #63, not sure. I notice two possibly related incorrect behaviors regarding mouse support in v0.3.1:

1. After editing a commit in Vim (which has terminal mouse support) with the C command in Status View, I can no longer click anywhere in GRV but the keyboard still works. Quitting and restarting GRV restores normal behavior. I suspect that something about mouse support isn't reset after coming back from an external command.

2. If I use GRV in a straight X terminal (Qterminal, KiTTY, etc.), with :set mouse false the scroll wheel scrolls through commits as though arrows were used. The same in Tmux scrolls up to Tmux's scrollback buffer as expected. When I set mouse however, the scroll wheel does nothing in both terminals. Given the existence of mouse-scroll-rows I assume that the scroll wheel should be supported, so this seems to be a bug.

If you need help duplicating this, let me know. Maybe something in my setup is atypical…

[rgburke]

1. Thanks for finding this bug. As you suggest, GRV is not re-enabling the mouse when vim finishes. I will look at fixing it.

2. The scroll wheel should work, it's currently working for me when using GNOME Terminal and xterm. To help track down what's going wrong could you please:

   • Run GRV with: grv -logLevel DEBUG
   • Scroll up and down only, then exit GRV.
   • Upload the generated grv.log file here. The log file will be generated in the same directory in which you run grv.

[vphantom]

Funny, the first time I ran it I got some form of crash, starting with:

panic: runtime error: invalid memory address or nil pointer reference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x20 pc=0x591aaa]
...

I seem to be getting these randomly once in a while, and if I try to start GRV again it runs fine. (So far this only happened in a specific repo, it may be specific to it.)

Attached is the crash log file and then the scroll log file:
grv-crash.log
grv-scroll.log

[rgburke]

Issue (1) should now be resolved on master, after editing a commit the mouse should continue to work.

Thanks for providing the logs. Could you try scrolling up and down a couple of times again using the latest code from master to see if it works now? If not could you attach the logs again please.

[vphantom]

I would, but I couldn't build using a temporary build environment (I don't have a Go setup). Is there any chance you could pre-release a binary?

Here is my console output from the build failure in case that's an easier fix. I suspect that there are non-Go dependencies the build script is trying to compile.
grv-docker-golang-build-failure.log

[rgburke]

Yeah sure, here is a static binary of the latest master: grv.txt (md5: a74b5dab5121a5900cf90097b1d850a2)

I had to add a .txt extension to the binary file so that github would allow it to be uploaded.

[vphantom]

Success! Scrolling works pretty much as expected. :)

Just FYI, coming from Tmux I instinctively expected the view hovered by the mouse to scroll, but in fact the currently active view is the one which scrolls. I can definitely get used to that (i.e. by clicking before scrolling), but I thought I should mention this difference in case you think it's of interest.

[rgburke]

Thanks for testing the scrolling, I'm glad it works.

I think scrolling the view the mouse is hovered over is a nice idea. I had a look into making this change but ran into issues with ncurses getting it to work. At the moment ncurses returns a failure when we call getmouse after doing a scroll down. In a very ugly and hacky way we interpret this error as a scroll down, as it's the only time we get the error. The alternative is that we can't support scrolling down. However due to this, we don't get a real event with coordinates meaning that we can't know which view the scroll event happened in.
TL;DR I like the idea but was unable to get it to work, I will keep it in mind to see if it's possible in future.