Remapped default key bindings not shown in the Help View about grv HOT 3 CLOSED

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 😄

from grv.

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?

from grv.

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.

from grv.