2

I want to map <leader>h to :bprev<CR>, with my leader key as \<space>, so I wrote the following in my init.vim (I also have nnoremap <space> <Nop> in my init.vim to override the default normal mode behaviour of <space>):

nnoremap <space> <nop>
let mapleader = "\<space>"
nnoremap <leader>h :bprev<CR>

but I have airblade/vim-gitgutter installed which adds a delay to my mapping because of plugin mappings <space>hp, <space>hu, <space>hs:

:verbose noremap <leader>h
n  <Space>hp     <Plug>GitGutterPreviewHunk
    Last set from ~/.config/nvim/bundle/vim-gitgutter/plugin/gitgutter.vim
n  <Space>hu     <Plug>GitGutterUndoHunk
    Last set from ~/.config/nvim/bundle/vim-gitgutter/plugin/gitgutter.vim
n  <Space>hs     <Plug>GitGutterStageHunk
    Last set from ~/.config/nvim/bundle/vim-gitgutter/plugin/gitgutter.vim
n  <Space>h    * :bprev<CR>
    Last set from ~/.config/nvim/init.vim
n  <Space>     * <Nop>
    Last set from ~/.config/nvim/init.vim
Press ENTER or type command to continue

This question indicates that I can remap plugin bindings by writing my custom bindings in a .vim file in .config/nvim/after/plugin, so I tried moving the definition of my mapping there instead along with <Nop> bindings for <space>hp, <space>hu, <space>hs, but that doesn't work because my <Nop> mappings still delay the execution of my <space>h mapping:

:verbose noremap <leader>h
n  <Space>h    * :bprev<CR>
    Last set from ~/.config/nvim/after/plugin/keys.vim
n  <Space>hp     <Nop>
    Last set from ~/.config/nvim/after/plugin/keys.vim
n  <Space>hu     <Nop>
    Last set from ~/.config/nvim/after/plugin/keys.vim
n  <Space>hs     <Nop>
    Last set from ~/.config/nvim/after/plugin/keys.vim
n  <Space>     * <Nop>
    Last set from ~/.config/nvim/init.vim

How can I override these mappings so that they don't interfere? Also, I have yet to find a decent "best practice" to avoid these types of conflicts - does one exist?

EDIT: I have tried putting exe :mapclear at the top of my new .config/nvim/after/plugin/keys.vim, but that clears all keybindings from all my plugins and my init.vim which is ... less than satisfactory - however, I don't think it's a terrible idea to move all my keybindings here and not rely on plugin defaults.

4

vim-gitgutter follows best practices with respect to mappings. Specifically, before it makes its maps it checks three conditions:

  1. The global variable g:gitgutter_map_keys is true.

One option is to let g:gitgutter_map_keys = 0, but then no mappings will be made and you would have to make the ones you use manually.

  1. There is not already a <leader>hs map

You can make your own <leader>hs map, but this won't help you because it would still cause a delay.

  1. There is not already a mapping to <Plug>GitGutterStageHunk

In my opinion the easiest method is to use your own preferred mapping,

nmap <leader>gsh <Plug>GitGutterStageHunk

This allows you to still use the functionality. Or, you can use a junk mapping;

nmap <plug>(disable-ggsh) <Plug>GitGutterStageHunk

Do this for all the right-hand-side maps you don't want vim-gitgutter to map to.

A different method, used when plugin do not follow mapping best practices, is to manually unmap what you don't like. It is easiest to do this in after/plugin/keys.vim:

nunmap <leader>hs

or within the VimEnter event:

autocmd VimEnter * nunmap <leader>hs
  • 3. worked for me - adding three nmap lines to my init.vim to override the functions <Plug>GitGutterStageHunk, <Plug>GitGutterUndoHunk, <Plug>GitGutterPreviewHunk. Thank you for also including a workaround for plugins that don't follow best practices! So far I do not need the after/plugin/keys.vim file! – jameh Mar 6 '18 at 4:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.