Conflict between remaps using plugins

user_9760159 0
Viewed 64

I am currently using the NERD commenter plugin to define certain mappings that allow me to comment/uncomment blocks of code. One of the default mappings is:

[count]<leader>c<space> Toggles the comment state of the selected line(s). If the topmost selected line is commented, all selected lines are uncommented and vice versa.(NERDCommenterToggle)

I have remapped this options using nmap <C-_> <plug>NERDCommenterToggle and vmap <C-_> <plug>NERDCommenterToggle

My intention is to toggle between commented and uncommented in normal and visual mode using <C-_>.

The conflict arises because I have set the spacebar as my leader key and I have also set it up as a remap for folding: nnoremap <space> za.

When I put all of this together on my .vimrc pressing <C-_> folds the part of the document if it is "foldable", otherwise it toggles the comments.

The only reason that I can think of for this to happen is that, behind the scenes, <C-_> is still calling the default mapping of the plugin, which, because it contains the leader key, which is mapped to the spacebar is folding the code.

I am not that deep into vimscript, so I don't know if this is the intended behavior but it seems to me very weird that even though I have remapped the NERDCommenterToggle command, it still calls the default map. I was under the impression that the <plug> handles were used to avoid this kind of problems.

If this is indeed the intended behavior, is there a way to create a map to NERDCommenterToggle without it conflicting with the original mapping?

EDIT:

I removed the mapping of my leader key to space and the problem persists, which doesn't make any sense to me. Basically now I have the maps:

  • nmap <C-_> <plug>NERDCommenterToggle
  • nnoremap <space> za

and for some reason they interfere with each other and pressing "control + /" (<C-_>) triggers the folding maps.

vim-plugin vim
1 Answers

Background

The whole point of <Plug> mappings is for plugin developers to provide a clean way for end users to make their own mappings without calling internal functions and such. Some of the benefits of that interface are:

  • ease of use for the end user,
  • possibility of changing the implementation without impacting the end user,
  • simplification of the documentation,
  • collision prevention,
  • etc.

Ideally, plugin developers should only expose <Plug> mappings, if only to prevent collision with other mappings, from other third-party plugins or by the end user. But that is entirely left to the developper: in no way does the use of a <Plug> mapping by the end user prevents the plugin developer from creating their own default mappings.

The problem

In this specific case, the author chose to create default mappings out of the box (g:NERDCreateDefaultMappings is set to 1) as well as their <Plug> equivalents. This leaves you with two mappings for the same feature (more, actually, because of modes, but let's keep it simple):

nnoremap <Plug>NERDCommenterToggle :call nerdcommenter#Comment("nx", "Toggle")'
nmap <Leader>c<Space> <Plug>NERDCommenterToggle

To which you add a third one:

nmap <C-_> <plug>NERDCommenterToggle

Since the default <Leader>c<Space> mapping is still there and your leader is <Space>, you are bound to find conflicts.

Plan A

Disable the plugin's ability to define default mappings with:

let g:NERDCreateDefaultMappings = 0

as per :help NERDCreateDefaultMappings. This puts you in control so you are free to build whatever mapping you need from the provided <Plug> mappings without the default mappings getting in the way.

Plan B

Note that it is also technically possible to "unmap" that pesky <Leader>c<Space> mapping with:

nunmap <Leader>c<Space>

But the plugin defines its default mappings after your vimrc is sourced so you can't simply add the line above to your vimrc as it will a) throw an error because the targeted mapping doesn't exist at that time, and b) not do anything useful anyway. Using that method efficiently opens quite the can of worms so I recommend plan A.

user_5468610
Related