11

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).

berkes
  • 26,996
  • 27
  • 115
  • 206
  • Use git, `git pull` won’t allow your changes to go away doing the merge instead. – ZyX Oct 07 '12 at 15:30
  • 2
    Better, fork this repository on github, add a possibility to customize the mappings (it is faster to do this by changing `noremap b …` to `execute 'nnoremap' get(g:, 'ruby_debugger_map_toggle_breakpoint', 'b') '…'`) and then do a pull request. With the suggested change mappings will be customized using `g:ruby_debugger_map_toggle_breakpoint` variable. – ZyX Oct 07 '12 at 15:36
  • 2
    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`](https://bitbucket.org/ZyX_I/frawor/src/a09e101e4a9a55e1bbbf6602a1ef2c4fcd839631/doc/frawor.txt#cl-731) in the same `~/.vim/after/plugin/mappings.vim` directory to save and then `map.map` to map them again, but to `rd*`, with normal `noremap` command for your NerdTree plugins). I believe you are not the only person needing ability to customize mappings. – ZyX Oct 07 '12 at 15:41
  • 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. – Mun Mun Das Oct 17 '13 at 14:38

2 Answers2

9

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.

Ingo Karkat
  • 167,457
  • 16
  • 250
  • 324
0

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>')
jameh
  • 1,149
  • 3
  • 12
  • 20