> On Monday 14 June 2010 11:50:18 Nathan Neff wrote:
>
>> What are some good guidelines to follow when trying to
>> map keys in a plugin?
>>
>> Currently I have the following setup in my plugin:
>>
>> I define a "g:GrailsVimMapleader" which defaults to
>> <leader>g
>>
>> Currently, all my plugin's commands are mapped to
>> g:GrailsVimMapLeader + another character. This should
>> help avoid conflicts, unless of course the user has <leader>g
>> mapped already.
>>
>> If the user wants to use a different set of leader keys,
>> the user can change g:GrailsVimMapLeader (for example, to
>> <leader><F3> or something.)
>>
>> However, I realize there's still a chance that key mapping
>> conflicts can occur.
>>
>> I would like to warn the user about key mapping conflicts, but
>> I don't want the warning to be annoying or ever-present until
>> the user fixes it.
>>
>> I know about the :map <unique> and maparg() function. Can
>> anyone give me suggestions for how to gracefully handle
>> keymapping conflicts?
>
> many ppl will have
>
> let g:no_plugin_maps = 1
>
> in their .vimrc to help avoid this very thing
>
> see
>
> :h filetype-plugins
>
> and scroll down a bit
>
> sc
So, to understand correctly, if the user has g:no_plugin_maps set to 1, then
the mappings won't be created? That's fine with me, if users have
g:no_plugin_maps set,
then the issue is out of the plugin author's hands, and that's fine.
I'm targeting novice-to-intermediate Vim users who want to use
Vim to edit Grails projects.
I want to provide these users with a reasonable default set of mappings,
as well as avoid annoying them with constant messages about mappings
that conflict.
I will check out Brett Stahlmann's suggestions and see what I can
apply to my own plugin.
Thanks for all feedback,
--Nate
--
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
No comments:
Post a Comment