On Saturday, September 8, 2012 9:01:47 AM UTC-5, Timothy Madden wrote:
> Hello
>
>
>
> I have been reading the help files on writing plug-ins, and I have
>
> learned how plug-ins should define mappings starting with the <Plug>
>
> virtual key name, that expose functionality of the plugin, like this:
>
> noremap <unique> <Plug>MyPluginInit ...plugin-commands
>
> noremap <unique> <Plug>MyPluginOpen ...plugin-commands
>
> noremap <unique> <Plug>MyPluginClose ...plugin-commands
>
>
>
> Than such mappings are used again in user-scope mappings, this time in a
>
> way that allows user to both:
>
> - see if there is a conflict with an existing mapping, and
>
> - create a different mapping for the same functionality
>
> These user mappings are defined like:
>
>
>
> if !hasmapto('<Plug>MyPluginInit')
>
> map <unique> <Leader>pi <Plug>MyPluginInit
>
> endif
>
>
>
> if !hasmapto('<Plug>MyPluginOpen')
>
> map <unique> <Leader>po <Plug>MyPluginOpen
>
> endif
>
> ....
>
>
>
> This is a good way to define mappings in user space, while at the same
>
> time allow user to change them, and to get an error when a conflict arises.
>
>
>
> However for command names I do not see the same level of indirection, to
>
> provide this flexibility. For command names, all the plugin author can
>
> do is to define the command only if it is not already there, like:
>
>
>
> if !exists(':Bp')
>
> command Bp ...plugin-breakpoint-command
>
> endif
>
>
>
> if !exists(':Up')
>
> command Up ...plugin-stack-trace-up-command
>
> endif
>
> ...
>
>
>
> Is there a way to define a command in my plugin in a way that allows
>
> user to change the command name in case of conflicts ? And that can also
>
> be detected by the plugin script, in order to resolve the conflict ?
>
>
>
> Also, I have recently forked (copied and modified) an existing plugin,
>
> and I only made a number of small changes initially, not related to the
>
> entry points in plugin mappings and commands. But at this moment
>
> automatically all these mappings and commands conflict with the ones in
>
> the original plugin (since they are duplicates of the original). Is
>
> there way to prevent this ? Ideally, is there a way to have the
>
> <Plug>MapName mappings and the commands depend on the script name ?
>
> Preferrably in a simple enough way that can be included in the
>
> documentation, and that user can understand and use.
>
>
>
> Thank you,
>
> Timothy Madden
I think the best way is just to make sure your names are likely to be unique.
Don't use <Plug>Up, use <Plug>MyNiftyPluginName_Up.
--
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
