Remapped default key bindings not shown in the Help View
marcelpaulo opened this issue ยท 3 comments
When a default key binding is remapped, the new mapping is not always shown in the Help View
.
Here's my ~/.config/grv/grvrc file:
map All " " <grv-next-page>
map All b <grv-prev-page>
map All <C-n> <grv-show-available-actions>
map All d <grv-remove-view>
map All q <grv-exit>
map All <C-f> <grv-filter-prompt>
set commit-graph true
As you can see, I remapped:
Key | Default mapping | New mapping |
---|---|---|
q |
<grv-remove-view> |
<grv-exit> |
<C-f> |
<grv-next-page> |
<grv-filter-prompt> |
b |
<grv-branch-name-prompt> |
<grv-prev-page> |
and added these new mappings:
Key | Mapping |
---|---|
" " |
<grv-next-page> |
d |
<grv-remove-view> |
<C-n> |
<grv-show-available-actions> |
Here's the Help View
:
Remapping not shown: q
Remapping shown on both default and new mapping: b
Mapping not shown: " "
I just realized now that the filter actions are not shown in the Help View
.
I fear I got a little lost looking at these mappings and remappings !
Thanks for trying out the help view. It's still a work in progress so I can't guarantee it will be completely correct yet ๐
The points you've raised above should now be addressed apart from:
Remapping shown on both default and new mapping: b
There is still separate binding entry for b
in the RefView binding table (on latest master):
This is because internally grv creates the following bindings by default:
map RefView b <grv-branch-name-prompt>
map CommitView b <grv-branch-name-prompt>
and bindings in specific views have precedence over bindings defined for all views. So for example when you add your binding:
map All b <grv-prev-page>
The key b
will map to <grv-prev-page>
in all views apart from the RefView and CommitView. There is currently a workaround for this by doing:
unmap RefView b
unmap CommitView b
I hope this makes sense. It may seem odd for bindings to work like this however it allows us to have view specific key bindings so that keys can be reused. For example, in the RefView c
means <grv-checkout-ref>
while in the GitStatusView it means <grv-action-commit>
. At the same time bindings which should apply to all views can be applied to the All view (as long as the keys aren't overridden by a specific view).
I'm also wondering if we should have another variant of the map
command which acts more intuitively. For example doing:
map b <grv-prev-page>
Means b
maps to <grv-prev-page>
everywhere which is what most people will probably want and expect. What do you think?
bindings in specific views have precedence over bindings defined for all views
It makes all the sense and it's an excellent idea.
I'm also wondering if we should have another variant of the map command which acts more intuitively
As I didn't know about the mapping precedence rule, I instinctively thought that map All
would trump any other mappings for the same key. Perhaps it would feel more intuitive to have map All
trump any specific mappings, and map key function
(without the view) to fill in mappings where they're not already defined.
Having said that, I confess I'm in doubt if the other way around, as you suggested, wouldn't be better. The fact is: it would be useful to have a map
version that would trump all other mappings.
The points you've raised above should now be addressed
Hey, thanks for that, I've tried it, and it's working fine !
grv is a really a damn good software ! I'm not a developer, so I use git just to clone software I build locally and for my bash scripts and config files, but I can't live without grv anymore.
EDIT: Forgot to mention that unmap <view>
indeed works as a workaround.
Thanks for the feedback. Once I've finished the help view I will look into adding a map
command that trumps everything, we can then decide if that's a helpful solution.
I'm glad you find GRV useful, it's nice when people use your software and give feedback. I really appreciate all the tickets you raise, you always spot things I miss ๐