How to deal with two vim plugins having the same mapping?

Question

I have two plugins (todo.txt-vim and vim-buffergator) that both map the

<localleader>b

command (for .txt files at least). One plugin ended up dominating the other.

I solved this by removing the mapping from one of the plugins, but this is hardly ideal long term (plugin updates, moving to new machines and so on)

What's a good way of dealing with the problem? Does vim have any facility for accessing a 'dominated' plugin...

Answer 1

If the plugin have been (dare I say: correctly) been designed with the end-user in mind, they should be defining their mappings with something like

if !hasmapto('<Plug>Something')
    nmap <leader>b <Plug>Something
endif

If that's the case, you just need to choose either one of the two default mappings and override it with something like

nmap someotherkeybinding <Plug>Something

in your .vimrc (or init.vim file in nvim case).

If not, open an issue on the plugin repositories, and even better provide a PR/MR to the maintainer that implements the feature.

Note: if all the mappings are <buffer>-local, it's much more complex to do correctly. (I wonder whether I haven't already answer on the topic here or on SO....)

Answer 2

One thing to notice is that, in your specific case, the mappings are not exactly the same.

Plug-in todo.txt-vim creates a buffer-local mapping for <LocalLeader>b for filetype todo (which the plug-in registers for files named todo.txt and similar variations):

nnoremap <script> <silent> <buffer> <localleader>b :call todo#txt#prioritize_add('B')<CR>

Plug-in vim-buffergator, on the other hand, creates a global mapping for <Leader>b:

nnoremap <silent> <Leader>b :BuffergatorOpen<CR>

Since one mapping is local and the other global, the effect will be predictable and consistent. Local mappings always take precedence over global ones, so in this case the mapping from todo.txt-vim will be the one that's active in a buffer with filetype todo. Once you move to a buffer with a different filetype, the global mapping from vim-buffergator will once again get active (it's not clobbered by the other definition, both still exist, though in todo buffers where a local mapping also exists it will take precedence.)

For cases such as this one, another alternative you have other than disabling one of the mappings is to set distinct leader key sequences for global and local mappings, which is actually possible since <Leader> and <LocalLeader> are actually distinct (even though by default they map to the same character, backslash.)

For example, to keep backslash for global mappings but use "space" for local ones, you can add the following to your vimrc:

let g:maplocalleader = '<Space>'

In your situation, that would keep \b for the vim-buffergator mapping and would use <Space>b for the todo.txt one.

This might affect many (half?) of your existing mappings, so it might take some getting used to... You'll need to "learn" which mappings are local and which are global (though typically that should be mostly obvious since the local ones are normally attached to a specific filetype.)

See :help mapleader and the section on maplocalleader that follows for more details.

Answer 3

This is a function of the order in which the plugins are loaded.

With Vim8 native package management, all plugins in ~/.vim/pack/*/start are automatically loaded in alphabetical order.

Consider moving them to ~/.vim/pack/*/opt and controlling the sequence with packadd commands in your ~/.vimrc.

If you're using another package manager, the order of package manager functions called in your ~/.vimrc is probably the same order that they're loaded. Use :scriptnames to confirm the order.

If you don't want to worry about package order, create a file ~/.vim/after/plugin/mappings.vim and put your preferred mapping command there. It will get sourced after the plugins.