Add and use evil-collection-define-key, which is a custom keybinding function
that checks evil-collection-key-{white,black}list before binding each key and
stores a record of the keybindings in evil-collection-bindings-record.
Modify evil-collection-util-inhibit-insert-state to conform to
evil-collection-define-key.
Though `pdf-view-next-line-or-next-page` and the `previous` version
both have number arguments, vi-style number arguments do not seem to
work. Even more strangely, if I remove the `dotimes` and change the
number arguments from `1` to `2` the pdf is still only scrolled
once. In `evil-emacs-state`, `M-2 <down>` works just fine in the
original version.
Though `pdf-view-next-line-or-next-page` and the `previous` version
both have number arguments, vi-style number arguments do not seem to
work. Even more strangely, if I remove the `dotimes` and change the
number arguments from `1` to `2` the pdf is still only scrolled
once. In `evil-emacs-state`, `M-2 <down>` works just fine in the
original version.
Instead of using hooks to ensure keybindings, use `evil-define-minor-mode-key`,
which combine `evil-define-key` and `evil-normalize-keymaps` to ensure that
bindings take effect for minor modes.
Per PR feedback, additional functionality is supported. Also, the require
statement is more defensive for those users that don't have `git-timemachine`
installed as a dependency.
Supports evil bindings for git-timemachine. On my machine, git-timemachine
starts with evil in normal mode, which is problematic when trying to access the
keybindings "n" and "p", which navigate to the next and previous revisions.
Additionally, normal mode eclispses "q", which exits the mode.
I tried using `(evil-set-initial-state 'git-timemachine-mode 'motion)`, but that
didn't work. I assume this is because `git-timemachine` is a minor-mode. To work
around this, I used `add-hook` to ensure motion mode was the initial state.
Once motion mode is the initial state, "p" and "q" become available.
Unfortunately, "n" is still not. To get around this, I used a buffer-local
binding in the local motion state map to map "n" appropriately. One known
shortcoming of this approach is that there is no cleanup done after exiting the
mode.
Any suggestions are eagerly welcomed. Forgive any crude techniques that I used
to get this functioning. I just wanted to broach the discussion with some of the
other maintainers to get some insights and hopefully augment my implementation
as needed.