Hi,
> I have a question for you plugin developers (but I am interested also
> in a user's perspective). What do you think is the best approach to
> deal with a conflicting mapping (i.e., a mapping already defined
> elsewhere) in a plugin?
>
> I currently define my plugin's mappings with <unique>, but from time
> to time users report `E227: mapping already exists` errors as bugs,
> so I am not sure that this is the best approach.
I do use <unique> in my plugins. But only if the user doesn't override the
default keybinding with his own. I rely on <plug>mappings to do so.
If the user report the error, well we need to explain her/him what can be done
to silence the error. The user has to make a choice which we cannot do for
her/him: either to continue with the keybinding defined in the .vimrc or
provided in another plugin, or to choose another keybinding for our plugin.
In my ftplugins, I've used <unique> <plug>ged mappings a few times, but I'm not
sure this is the best thing to do.
Which reminds me in a few places I've replaced <unique> with another approach
that issues a less intrusive warning.
It's used with:
nnoremap <Plug>TogglePreviewIfHold :Toggle Cpreview_if_hold<cr>
call lh#mapping#plug({'lhs': '<localleader>tpw', 'rhs':
'<Plug>TogglePreviewIfHold'}, 'n')
With lh#mapping#plug being defined over there:
https://github.com/LucHermitte/lh-vim-lib/blob/master/autoload/lh/mapping.vim#L99
HTH,
--
Luc Hermitte
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_use+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
