Overriding a remapping from a plugin?

Question

After installing vim-ruby-debugger that plugin "hijacks" several mappings. Like <leader>n, or <leader>t which I use for respectively NERDTreeToggle and Command-T find.

The culprit is found at the hardcoded mappings in this ruby-debugger.

I'd prefer to have these remapped as <leader>rdX, i.e.: prefixed with *r*uby-*d*ebugger. Obviously, I could simply hack the plugin and change the mappings there. But that seems a bit too hackish (and will probably break on updates).

How can I unmap these mappings, so vim will fallback to my own mappings again? And so that I can remap the commands in my .vimrc (where it should be, IMHO).

Incommodious

Use git, git pull won’t allow your changes to go away doing the merge instead. – Impearl

Better, fork this repository on github, add a possibility to customize the mappings (it is faster to do this by changing noremap <leader>b … to execute 'nnoremap' get(g:, 'ruby_debugger_map_toggle_breakpoint', '<leader>b') '…') and then do a pull request. With the suggested change mappings will be customized using g:ruby_debugger_map_toggle_breakpoint variable. – Impearl

Second solution is much better then using some sort of workaround (like putting your mappings that should not be overriden to ~/.vim/after/plugin/mappings.vim, the first suggested solution or using some sort of my map.maparg in the same ~/.vim/after/plugin/mappings.vim directory to save and then map.map to map them again, but to <leader>rd*, with normal noremap command for your NerdTree plugins). I believe you are not the only person needing ability to customize mappings. – Impearl

As your linked line suggests, the plugin would not set the mappings if you add let g:ruby_debugger_no_maps=1 in your .vimrc file. – Overbuild

Answer 1

First, I agree with ZyX's comments that this is a problem in the plugin that should be fixed. Please ask the plugin author to provide customization.

There is no easy way to unmap, because Vim does not remember the original mappings when a mapping is overridden. You have to make a note of the original mappings (:map ... when the offending plugin is temporarily disabled, or look in the Vim script for their definitions), then re-execute them after the offending plugin has been loaded (minus any <unique> flags it may have, as these will cause errors on re-execution). This cannot be done in .vimrc, it is sourced first; I would recommend a place like ~/.vim/after/plugin/zzzmappings.vim for this.

Alpestrine

Answer 2

I keep all of my mappings in after/plugin/keys.vim. This seems to ensure that they always take precedence over plugin mappings. (I use a bunch of plugins, and the collisions seem taken care of) (here's my nvim config)

FWIW, I also keep filetype-specific mappings in the same folder, but write them as autocmd FileType commands with the <buffer> keyword. For example, the following is a mapping that conflicts with bullets.vim's ToggleCheckbox function (it adds an empty checkbox to the bullet if there is none)

autocmd FileType markdown nnoremap <buffer> <expr> <leader>x (getline('.') =~ '^\s*- \[' ? ':ToggleCheckbox<cr>' : '0/-<space><cr>la[<space>]<space><esc>')

Chronic