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
