Missing documentation: how to close pop-ups
vphantom opened this issue · 14 comments
Hello,
Thank you for GRV. :) In my migration back to Vim from VScode, GRV fills an important missing role. I tend to have GRV running at all times in a Tmux tab now, with editors in others. With GRV v0.3.1 I'm encountering a road block: if I run anything that opens a pop-up, I have to killall -9 grv.
For example, :!ls opens a centered window with its output and exit status, but I can't close it. All I can do is move up and down in the output with the arrow keys, but nothing I could come up with actually closed it.
Am I missing something? 🤔
I might as well mention that I'm experimenting with launching shell commands because I'm looking for a way to launch Vim from GRV, for quickly editing a file before finalizing its staging. Is there a way to launch an external command and give it the full terminal until it quits? I realize that :!vim ${file} is probably not what I'm looking for, given that it's windowed inside GRV. Should this be another issue?
Thanks for reporting this issue. For commands that are non-interactive (they don't expect any input) it should be possible to close the popup using q. There is an easy to miss message in the bottom left hand corner that provides the key to press (highlighted in the image below):
So when running :!ls it should be possible to close the window using by pressing q.
Interactive commands like :!vim {$file} won't work at the moment as they need to be run in the controlling terminal. But I agree that it's a nice idea and GRV should support that functionality. I think the best approach would be to make running a shell command :!... behave the same way as vim does. Then running :!vim ${file} will hide GRV, pass over control of the terminal to vim until it's finished and then GRV can resume. I will have a look at implementing this.
Ah ha! Then the culprit must be this configuration line of mine:
# Hotkey to quit
map All q ":q<Enter>"
…because as it is, I have the "Loaded XXX commits" line, but the following one is empty. If I remove that configuration line, then I see "Press q to close command output". I now get the intended behavior by using these explicit maps instead:
# Hotkey to quit
# (Don't map "All" because that would break pop-up dismissal.)
map CommitView q ":q<Enter>"
map DiffView q ":q<Enter>"
map GitStatusView q ":q<Enter>"
map GitSummaryView q ":q<Enter>"
map RefView q ":q<Enter>"
map RemoteView q ":q<Enter>"
Thank you for the hint. :)
As for Vim-style !, since GRV already launches an external editor for commit messages, it seems like the bulk of the mechanism would already be in place for launching one on the currently selected file. That said, since I'm using Tmux I devised a very friendly work-around with @:
# Hotkey to edit current file
map CommitView e ":@tmux new-window vi ${repo-workdir}/${file}<Enter>"
map DiffView e ":@tmux new-window vi ${repo-workdir}/${file}<Enter>"
map StatusView e ":@tmux new-window vi ${repo-workdir}/${file}<Enter>"
…the trick here is that when a new Tmux tab is launched with a command, it'll take focus but also close automatically when the command exits. The result is almost identical vs having Vim in the GRV tab itself.
Master has been updated so that ! behaves in the same way as vim. Although I think your solution using tmux is a lot nicer!
Thanks for this. Both the :!vi and the :@tmux new-window vi are great features.
But I found the file it wants to edit is sometimes not the right one ?
Not sure the steps I took to get there but it happened often. It seemed to keep editting a previous file and not the one in the commit.
@mckellyln Currently the file variable is set when a file from the diff stats part of the DiffView is selected or when a file in the StatusView is selected.
There is a GRVVariableView which can be useful to see what GRV thinks the current value of all variables are. In the gif below we switch to the CommitView, run :addview GRVVariableView and change the orientation with <C-w>t. This allows us to see how the variables change as different rows in each view are selected:
Let me know if you think GRV is missing a case where it should set the file variable.
@rgburke thanks. I did this and it shows the problem.
Initially when selecting commits the file variable is blank and the repo-workdir is correct. But when I go to diffs window and then to the line where the file is specified - the file variable is updated to be correct. But then if I go back to the commit view the file variable remains what it was - and is now no longer correct.
Perhaps with each <Tab>/<Shift><Tab>(changing windows/views) the file variable should be cleared ?
I'm using:
GRV - Git Repository Viewer v0.3.1-21-gf53e3d1 (compiled with go1.11.4 at 2019-02-27 21:00:55 EST)
Just curious, is there a way to not have the
Press any key to continue
prompt when exiting vi after editting a file ?
(using the map of e to :!vi ${repo-workdir}/${file})
And thank you for awesome grv.
A new config variable has been added which controls whether the Press any key to continue message is displayed. Add set input-prompt-after-command false to your grvrc and it will no longer appear.
For the shell variable behaviour, at the moment a variable will keep a value until a new one is set. So until another filepath is selected the file variable will retain the value of the previously selected filepath. The variables represent the most recently selected values, rather than the currently selected row.
The thinking was that as long as a row is selected with the file path you're interested in, then the file variable should be the value you expect. We could clear the variable when a different view is selected, although it could also be useful to still be able to use the file variable later on in a different view. I'm not sure if there's a big advantage for clearing the variables over the current behaviour.
@rgburke thank you so much.
I understand the file variable will remain unchanged until it is updated with a new one, and I can see that might be useful.
I think its my view that upon entering a new diff view, if the file(s) in the current diff view are not the same as the previous file variable then it should be cleared, as I'd rather get a "no file selected yet" type message than editing the wrong file.
I really appreciate your code and effort, thanks again.
Perhaps a new variable such as diffviewfile that acts this way ?
But its fine as is. You are so good about fixing bugs and adding features so I keep suggesting things.
@mckellyln It is great to see @rgburke caring about this project as much as he does. Not to go further off-topic, but I'd gladly make a one-time donation if there were an easy way to do so. hint 😃
@mckellyln Sorry for the delay, last week was very busy. A diff-view-file variable has been added which should behave the way you want.
Thanks for the kind words guys. Knowing that people find GRV useful is payment enough for me.
Thanks, its awesome.