- In the past we have discussed automatically loading scripts a few times. I now implemented one of the solutions in Vim 7. See the help text below (theMessage 1 of 50 , Feb 8, 2005View SourceIn the past we have discussed automatically loading scripts a few times.
I now implemented one of the solutions in Vim 7. See the help text
below (the FuncUndefined event already existed, I kept the text for
I wonder if this is the right solution. Is this not too complicated?
Is it sufficient? Is there a better solution?
The snapshot I uploaded last night includes this functionality, so you
can try it out.
AUTOMATICALLY LOADING FUNCTIONS ~
When using many or large functions, it's possible to automatically define them
only when they are used. There are two methods: with an autocommand and with
the "autoload" directory in 'runtimepath'.
Using an autocommand ~
The autocommand is useful if you have a plugin that is a long Vim script file.
You can define the autocommand and quickly quit the script with |:finish|.
That makes Vim startup faster. The autocommand should then load the same file
again, setting a variable to skip the |:finish| command.
Use the FuncUndefined autocommand event with a pattern that matches the
function(s) to be defined. Example: >
:au FuncUndefined BufNet* source ~/vim/bufnetfuncs.vim
The file "~/vim/bufnetfuncs.vim" should then define functions that start with
"BufNet". Also see |FuncUndefined|.
Using an autoload script ~
Using a script in the "autoload" directory is simpler, but requires using
exactly the right file name. A function that can be autoloaded has a name
like this: >
When such a function is called, and it is not defined yet, Vim will search the
"autoload" directories in 'runtimepath' for a script file called
"filename.vim". For example "~/.vim/autoload/filename.vim". That file should
then define the function like this: >
The file name and the name used before the colon in the function must match
exactly, and the defined function must have the name exactly as it will be
It is possible to use subdirectories. Every colon in the function name works
like a path separator. Thus when calling a function: >
Vim will look for the file "autoload/foo/bar.vim" in 'runtimepath'.
The name before the first colon must be at least two characters long,
otherwise it looks like a scope, such as "s:".
Note that the script will be sourced again and again if a function is called
that looks like it is defined in the autoload script but it isn't.
hundred-and-one symptoms of being an internet addict:
50. The last girl you picked up was only a jpeg.
/// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
/// Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ Project leader for A-A-P -- http://www.A-A-P.org ///
\\\ Buy LOTR 3 and help AIDS victims -- http://ICCF.nl/lotr.html ///
- 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.