search

emacs-evil / evil

The extensible vi layer for Emacs.
GNU General Public License v3.0
3.33k stars 281 forks source link

undo-tree-visualizer key mapping #408

Open TheBB opened 10 years ago

TheBB commented 10 years ago

Originally reported by: Anonymous

The undo-tree-visualizer key remappings do not work for me. In particular:

<remap> <evil-next-line>        undo-tree-visualize-redo
<remap> <evil-previous-line>    undo-tree-visualize-undo

Note that I have in my init.el (as recommended on several internet sites):

(define-key evil-normal-state-map (kbd "<remap> <evil-next-line>") 'evil-next-visual-line)
(define-key evil-normal-state-map (kbd "<remap> <evil-previous-line>") 'evil-previous-visual-line)
(define-key evil-motion-state-map (kbd "<remap> <evil-next-line>") 'evil-next-visual-line)
(define-key evil-motion-state-map (kbd "<remap> <evil-previous-line>") 'evil-previous-visual-line)

Maybe h,j,k,l should be remapped directly (or is there a better way to do the remapping to visual lines)? In addition, the help page is not helpful cause it shows the emacs commands primarily (some of which work, e.g. p, and some don't, e.g. n) and only the evil remappings at the bottom. Would it show the evil bindings directly if they actual keys are remapped?

Perhaps emacs mode should always be used for this buffer.

TheBB commented 10 years ago

Original comment by Frank Fischer (Bitbucket: lyro, GitHub: lyro):

Certainly conflicting remapping in different keymaps cause trouble. I have no idea what the correct solution is and would be happy for any suggestions. The problem is that Evil keymaps typically have priority over other keymaps, so the remapping in evil-motion-state-map shadows the ones in the undo-tree maps.

However, using remappings in undo-tree maps has certain advantages: it automatically adapts to user remappings and it ensures that those bindings are not active when Evil is deactivated. So replacing the remapping in undo-tree maps by direct bindings is not really an option.

Personally, I use visual-line motions only when visual-line-mode is active, i.e. using 

#!cl
(evil-declare-key 'motion visual-line-mode-map "j" #'evil-next-visual-line "k" #'evil-previous-visual-line)

Because I activate visual-line-mode only in few buffers (e.g. org-mode or latex) and not in undo-tree buffers, these bindings do not interfere.

Another option could be to place the undo-tree remapping in mode-specific maps using evil-declare-key as well, which take priority over ordinary Evil maps like evil-motion-state-map, but I haven't tested this approach, yet (something like 

#!cl
(evil-declare-key 'motion undo-tree-visualizer-mode-map [remap evil-next-line] 'undo-tree-visualize-redo)
(evil-declare-key 'motion undo-tree-visualizer-selection-mode-map [remap evil-next-line] 'undo-tree-visualize-redo)

i.e. replace the define-key lines in evil-integration.el by something like this, but without any warranty).

Oh, and I have no idea how those help pages work ;)