Re: How to avoid command name clashes from plugins ?

On 09/13/2012 10:49 PM, Charles Campbell wrote:
> Ben Fritz wrote:
>> On Saturday, September 8, 2012 9:01:47 AM UTC-5, Timothy Madden wrote:
>>> <snip>
>>>
>>>
>>> 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.
>>
> What I typically do is to provide two names; using Ben's style:
>
> com! MyNiftyPluginName_Up ...
> sil! com Up ...
>
> The first one guarantees that your command will be available with that
> MyNiftyPluginName_Up command. The user can then use cabbr to get
> whatever string s/he wants.
> Example:
>
> com! MyNiftyCmd echo "MyNifyCmd works"
> com Cmd echo "Cmd works the first time"
> sil! Cmd echo "Cmd works the second time!"
> cabbr UserVariantOfCmd MyNiftyCmd

Thank you. I eventually chose a variation like:

command DebuggerBreakpoint echo "Breakpoint command implementation"
if !exists(':Bp')
command Bp DebuggerBreakpoint
endif

In short it is the same approach as with mappings (using commands on two
levels for indirection), except for commands there is no special
construct like <Plug> for mappings.

This way I can document both command names, together with the definition
for the user-space :Bp command, so user can easily create the same
command with a different name in case of conflicts.

I prefer to explicitly check if exists(':Bp') because to my knowledge
silent! still records an error message in the message history. And then
scripts running in batch mode with vim -es that want the plugin will
terminate with an error exit code no matter what script actually does,
because the plugin runs into a name conflict that was never meant to
trigger an error.

Thank you,
Timothy Madden

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