Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 80 by [email protected]: Feature request: variation for <SID>
to return script base name
http://code.google.com/p/vim/issues/detail?id=80
When writing a plug-in, one of the problems is keeping commands and
mappings from conflicting the the user-defined ones, or more importantly
with the ones from other plugins.
For example the intermediate <Plug> mappings should start with the plugin
file name, like:
<Plug>MyPluginInit
<Plug>MyPluginOpen
<Plug>MyPluginClose
and plugin global settings should also use variable names starting with the
plugin name, like
let g:mypluginConfigFile = /...
lgt g:mypluginDataDir = /..
A plugin may also use buffer and tab variables, which can introduce
conflicts between plugins much like global variables, and can benefit from
a similar convention. The same for plugin commands:
command MyPluginInitCmd ...
command MyPluginConfigCmd ...
command MyPluginOpenCmd ...
Later, if you want to re-name your plugin you would need to change the name
for your plug-in, you need to change the names for these entry point. And
if you want to fork an existing plug-in to start your own, the first thing
you need to do is to rename it..
Could a variation of the <SID> macro be introduced, something like
<PluginScript>, or <SID:name>, to expand to the script base name when used
in mappings, global variables and global function names ?
Then authors could write:
noremap <unique> <Plug><SID:name>Init
noremap <unique> <Plug><SID:name>Open
noremap <unique> <Plug><SID:name>Config
command <SID:name>InitCmd ...
command <SID:name>ConfigCmd ...
command <SID:name>OpenCmd ...
and code like:
if exists('g:<SID:name>ConfigFile')
...
endif
This is for plugin authors, and regular users would not be affected by
<SID:name> expansion. Even plugin documentation need not be changed. But if
user ever manages to download two plugins with the same name, or maybe two
different versions of a plugin (during development, testing), all the user
needs to do is rename one of them, and the entire plugin interface changes
automatically with the file name.
A similar potential for conflicts exists within python code if two plugins
use python (I do not user other integrations). To avoid conflicts plugins
should encapsulate all their code in a single python package/module, and
the script passed to :pyfile should do nothing more than import that module
(in particular there should be no global functions, classes, variables). So
<SID:name> should also expand in :python commands...
--
You received this message from the "vim_dev" 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
