Feature request: variation for <SID> to return script base name

[GoogleCodeExporter]

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

Original issue reported on code.google.com by terminatorul@gmail.com on 8 Sep 2012 at 5:45

[GoogleCodeExporter]

The whole point of <SID> is that the corresponding name is not visible from 
outside its defining script. IMHO using what you propose would defeat this 
goal. To pass a name visible from outside the script, don't use <SID>, use 
<Plug>MyScriptName_ — or even start your function, command, or global 
variable name with just MyScriptName_ where MyScriptName is your script's name 
and where the underscore is there to prevent name collision with a different 
script whose name would start in the same way.

It is possible, however, to determine manually what <SID> means inside a given 
script, as follows:

1. Make sure the script has been run at least once in the present Vim session.
2. Find that script in the output of :scriptnames — the line with that 
script's name starts with a number, which is the "script number" of that script 
for the duration of the present session.
3. If, for instance, that script's number is 25, then the <SID> of that script 
is <SNR>25_ (with the underscore at the end) where <SNR> is a special code 
which should not collide with anything that your keyboard can normally produce.

See ":help <SID>" for a ddetailed discussion. How to find back the current 
script's number _in vimscript code_, rather than manually, has been discussed 
in the past, and I think that a way of doing it was found, but I don't remember 
the details. Maybe they've been written up as an article on 
http://vim.wikia.com/ (or maybe not), maybe you could try searching that wiki.

Best regards,
Tony.
-- 
There's more than one way to skin a cat:
    Way number 27 -- Use an electric sander.

Original comment by antoine....@gmail.com on 8 Sep 2012 at 11:54

[GoogleCodeExporter]

<SID> as it is should remain unchanged.

I am interested in the public interface for my plugin, that is the names meant 
to be visible outside the script.

I am looking for a way to include "MyScriptName_..." prefix for such names 
whithout  hard-coding it. I would like to be able to use an expression in-place 
of the prefix, that returns the script name (the same way <SID> returns the 
script ID, which is why I first thought about it), and I would like to use such 
a substitution expression in my:

 - mapping definitions, after the <Plug> key
 - command names
 - :python commands (and maybe other interfaces too)
 - global function names, if any,
 - global variables for plugin user settings/configuration
 - signs, even highlights, etc

An even better approach would be if Vim would allow script author to redefine 
the value of the substitution expression, the same way a user can re-define 
<Leader>. The script name would be only the default value.

In this way, if either the author or the user decides the file should be 
renamed (perhaps to avoid a conflict, or just to start a fork for an existing 
plug-in), all the public interface adjusts automatically with the new name.

PS:
Te get the current value of <SID> I would do:
   :map <Plug>Some-UUID-here <SID>
   :echo "Script ID: " . maparg('<Plug>Some-UUID-here')
   :unmap <Plug>Some-UUID-here

Original comment by terminatorul@gmail.com on 11 Sep 2012 at 12:55

[GoogleCodeExporter]

> In this way, if either the author or the user decides the file should be
> renamed (perhaps to avoid a conflict, or just to start a fork for an existing
> plug-in), all the public interface adjusts automatically with the new name.

This is a one-time action that hardly ever occurs; and it can be already solved 
via a simple :%s// command. Also, all existing plugins would need to be 
modified before one could benefit from this.

I'm sorry, but I don't see how this could be useful in relation to the 
implementation, testing, and documentation effort. Please provide additional 
arguments or consider closing this request.

Original comment by sw...@ingo-karkat.de on 11 Sep 2012 at 1:04

[GoogleCodeExporter]

Ok
I have no more arguments...

Original comment by terminatorul@gmail.com on 11 Sep 2012 at 2:15

[GoogleCodeExporter]

Original comment by chrisbr...@googlemail.com on 30 Sep 2014 at 6:16

• Changed state: WontFix