- ... will ... of ... But then the file scope is a scope more generic than s: and g: etc. So script variables should not be named s:longpackagename:foofuncMessage 1 of 50 , Feb 8, 2005View SourceBram Moolenaar wrote:
> Servatius Brandt wrote:
> > In my opinion it's a bit difficult to understand. Function names
> > get very long because of the path prefix, and I don't like the useof
> > the colon because it can be confused with the scope prefixes.But then the file scope is a scope more generic than "s:" and "g:" etc.
> In a sense the name is a scope name. A scope in which functions are
So script variables should not be named
and then the a script could not be named "s.vim". If we require the
we would have to forbid single letter subdirectories under "autoload",
but the "s:" scope specifier in front of the "longpackagename:" scope
specifier does not look intuitive to me. Of course, it is possible and
I'll get used to it.
Hmm, maybe I misunderstood something. Is the "longpackagename:" just
a new scope specifier that can be used instead of but not in conjunction
with the single letter scope specifiers?
> Function names will get longer, that is true. You can use a FuncRefSo the "longpackagename:" is just a generalisation of the "s:" prefix?
> variable if that becomes a problem:
> :let s:Foo = function('longpackagename:foofunc')
> :call s:Foo()
> The long name is required to avoid name clashes, since all function
> names are global (script-local ones get a special number, so that they
> can be invoked from a mapping, but they are still global).
So that it allows to call functions between different scripts of
a group? Then maybe it would be useful to have also
a "./longpackagename" or "../longpackagename" beginning at the directory
of the current script rather than the "autoload" directory.
> > I think it's not sufficient since it expects script writers to speedscript
> > up each of their scripts seperately.
> > As a user I would prefer a method that allows to autoload every
> > I've downloaded somewhere, even if the script writer didn't careabout
> > this issue.But plugins are autoloaded anyway. The question is only when this
> I don't agree with that. The script writer is repsonsible for what he
> writes. And it's nearly impossible to guarantee autoloading a script
> works, you have to carefully check that it's OK.
happens: at startup or when needed. I'm not sure that it is really
impossible to postpone loading plugins. Maybe it is, but from a user's
view it would be useful if this worked for every script.
> > It would be good if I could do this without changing thetake
> > script and even without looking into it.
> Yes, but that is not possible. The solution you describe does not
> care of:See my reply to Antony Scriven's post.
> - user commands that are defined in the script
> - mappings that are defined in the scriptIt should be possible to generate corresponding mappings in loader.vim
that undefine themselves, source the correct script defining them and
execute this new definition.
> - default values for global variables (used as a setting)This would not be necessary: Global variables executed in a script are
defined when the script is sourced the first time. Global variables
defined as a setting in the user .vimrc file (before sourcing the
plugins) are not affected when the sourcing is postponted to the time
the plugin is actually used.
> - probably a few other things.Don't know.
> It's very complicated as well. Sorry, I just don't find it
I tried to think simple: we need just a mechanism to postpone the
sourcing of the plugin and to map its user interface (functions,
commands, mappings) to something that triggers the sourcing of the
plugin to get the correct definitions before execution.
As I said, it's just an idea, not fully worked out.
Servatius Brandt Phone: +49 89 636-41504
Fujitsu Siemens Computers Fax: +49 89 636-48716
EP SW AD C++ Email: Servatius.Brandt@...
- Really hot topic ;) Remarks to prior posts: adding path as prefix to a function isn t necessary (if there is a autoload folder) because the place of the fileMessage 50 of 50 , Mar 7 6:21 AMView SourceReally hot topic ;)
Remarks to prior posts:
adding path as prefix to a function isn't necessary (if there is a
autoload folder) because the place of the file tells already that the
function should have the prefix [...].
So the problem doesn't arise that s.o want's to use your function
you haven't thought of (and you've forgotten to add the
The nice effect of having errormessages which tell where the function
was defined can be implemented without thinking of autoloading.. Just
save the origin and the functionname and you can create errormessages
error in line xy of function directory:functionname
or commandline:functionname if it's a function written at the vim
1 sharing of the source (reusable code)
2 should be updateable ( s.th. like update all would be nice)
3 the implementation should be loaded when the function is used to
speed up start up time of vim.
4 due to different keyboard layouts and personal preferences everybody
want's to have is own (different) keybindings..
1: If you only want to use one function of another script you have to
include the whole file.. So the most used way was to copy/paste the
function (I think)
2: If you're using functions from other scripts you run the risk of
braking things when you intall a newer version of that script
3: The example netrw was mentioned earlier that it's a huge script so
it makes no sense to load the whole script if you want to use only
limited functionality of it.
I'm not such an experienced vim programmer because I'm using vim/linux
(gentoo ;) for little longer than a year now.o
Point 4 (personal keybindings) lead me to the idea of seperating the
description of the userinterface (commands/ maps and so on) from the
script functionality.. So all users on a linux box might share the
vimscript implementation but may use different ui-descriptions:
So this might end in a vimfile which might look
--- ui_myscript.vim - start
" This file describes the commands/keymappings
map \thislineUpperCase call library/experimental/MarcsUsefulScripts/MakeThisLineUppercase()v>0.2
--- ui_myscript.vim - end
I think you've already noticed that I'm moving towards some kind of
version-control (as gentoo uses it). So you can be sure if you limit
yourself to one specific version that it will work in the future, too.
I like the idea of having a "vim library":
in more detail:
If you combine a system like this you can do a lot..
Let me give an example
It should be easy to create a parser for your vim scripts which lists
all used functions.. So you can automatically delete all outdated
functions which you don't need anymore. But you can also do the
opposite: Write a script which downloads all missing functions/ updates
all functions (If you're using something like cvs/ftp)
But I don't know how much time it takes to source every function..
Of course you'll tell me that it will be much effort to write the
directory in front of everyt functions (as in the example of the user
interface script) But it should be easy to write a script which looks
the directory/version up perhaps using s.th. similar to ANtags.. The
difference would be that only the users who develop have to use the
tags and you can easily automate operations like 'find all wrong
invalid function references and correct them.
And I'm sure many thins would become simpler eg:
Use functionality of matchit.vim in your own indent expressions..
or use the functionality privided in the imaps.vim from the LaTeX suite
to jump to the next <+description+> tag using C-j ....
And if you are writing a script which has a lot of functions why not add
an using.vim file with aliases or function references in your script
directory providing a dictionary for the vimscript interpreter so that
it does know which function you want to have?
notes.vim # < containing notes about the changes, author of the script myscript
-- experimental/myscript/using.vim - start
function AddElementToArray(): library/stable/array/AddElementToArray()v>1.2
function RemoveElementFromArray(): library/stable/array/RemoveElementFromArray()v>1.2
-- experimental/myscript/using.vim - end
-- experimental/myscript/function1-version.vim - start
"Call the functions and because of source using.vim vim does know
"where to look for the functions
-- experimental/myscript/function1-version.vim - end
So creating a "namespace" would become nothing more then writing such a
using.vim file which you (or others) can source..
Of course there would arise some conflicts but keep in mind that
everyone can fix them easily.
And you can also teach vim to first look for a function in the stable
directory, then at the expermental one.. So you can move the functions
from experimental to stable without changing your scripts.!
I'm sure I have forgotten some points or problems with a system like
that so reply to open my mind.