Mouse misbehavior in v0.3.1
vphantom opened this issue · 7 comments
This may be related to #63, not sure. I notice two possibly related incorrect behaviors regarding mouse support in v0.3.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. -
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 setmouse
however, the scroll wheel does nothing in both terminals. Given the existence ofmouse-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…
-
Thanks for finding this bug. As you suggest, GRV is not re-enabling the mouse when vim finishes. I will look at fixing it.
-
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.
- Run GRV with:
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
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.
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
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.
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.
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.