usr_52.txt For Vim version 9.2. Last change: 2026 Jul 27 VIM USER MANUAL by Bram Moolenaar Write larger plugins When plugins do more than simple things, they tend to grow big. This file explains how to make sure they still load fast and how to split them up in smaller parts. 52.1 Export and import 52.2 Autoloading 52.3 Autoloading without import/export 52.4 Other mechanisms to use 52.5 Using a Vim9 script from legacy script 52.6 Vim9 examples: comment and highlight-yank plugin Next chapter: usr_90.txt Installing Vim Previous chapter: usr_51.txt Create a plugin Table of contents: usr_toc.txt ============================================================================== 52.1 Export and import Vim9 script was designed to make it easier to write large Vim scripts. It looks more like other script languages, especially Typescript. Also, functions are compiled into instructions that can be executed quickly. This makes Vim9 script a lot faster, up to a 100 times. The basic idea is that a script file has items that are private, only used inside the script file, and items that are exported, which can be used by scripts that import them. That makes very clear what is defined where. Let's start with an example, a script that exports one function and has one private function: vim9script export def GetMessage(count: string): string var nr = str2nr(count) var result = $'To {nr} we say ' result ..= GetReply(nr) return result enddef def GetReply(nr: number): string if nr == 42 return 'yes' elseif nr == 22 return 'maybe' else return 'no' endif enddef The vim9script command is required, export only works in a Vim9 script. The `export def GetMessage(...` line starts with export, meaning that this function can be called by other scripts. The line `def GetReply(...` does not start with export, this is a script-local function, it can only be used inside this script file. Now about the script where this is imported. In this example we use this layout, which works well for a plugin below the "pack" directory: .../plugin/theplugin.vim .../lib/getmessage.vim Assuming the "..." directory has been added to 'runtimepath', Vim will look for plugins in the "plugin" directory and source "theplugin.vim". Vim does not recognize the "lib" directory, you can put any scripts there. The above script that exports GetMessage() goes in lib/getmessage.vim. The GetMessage() function is used in plugin/theplugin.vim: vim9script import "../lib/getmessage.vim" command -nargs=1 ShowMessage echomsg getmessage.GetMessage(<f-args>) The import command uses a relative path, it starts with "../", which means to go one directory up. For other kinds of paths see the :import command. How we can try out the command that the plugin provides: ShowMessage 1 To 1 we say no ShowMessage 22 To 22 we say maybe Notice that the function GetMessage() is prefixed with the imported script name "getmessage". That way, for every imported function used, you know what script it was imported from. If you import several scripts each of them could define a GetMessage() function: vim9script import "../lib/getmessage.vim" import "../lib/getother.vim" command -nargs=1 ShowMessage echomsg getmessage.GetMessage(<f-args>) command -nargs=1 ShowOther echomsg getother.GetMessage(<f-args>) If the imported script name is long or you use it in many places, you can shorten it by adding an "as" argument: import "../lib/getmessage.vim" as msg command -nargs=1 ShowMessage echomsg msg.GetMessage(<f-args>) RELOADING One thing to keep in mind: the imported "lib/getmessage.vim" script will be sourced only once. When it is imported a second time sourcing it will be skipped, since the items in it have already been created. It does not matter if this import command is in another script, or in the same script that is sourced again. This is efficient when using a plugin, but when still developing a plugin it means that changing "lib/getmessage.vim" after it has been imported will have no effect. You need to quit Vim and start it again. (Rationale: the items defined in the script could be used in a compiled function, sourcing the script again may break those functions). USING GLOBALS Sometimes you will want to use global variables or functions, so that they can be used anywhere. A good example is a global variable that passes a preference to a plugin. To avoid other scripts using the same name, use a prefix that is very unlikely to be used elsewhere. For example, if you have a "mytags" plugin, you could use: g:mytags_location = '$HOME/project' g:mytags_style = 'fast' ============================================================================== 52.2 Autoloading After splitting a large script into pieces, an imported script is loaded and executed at the moment the importing script is sourced. Every :import loads the imported script to find the items defined there. However, if an imported script is large, then the startup time may become noticeably slower, but on the other hand if there are errors they will be detected at import time. To avoid long startup times, the loading of an imported script may be deferred until it is actually needed. This is done with the autoload keyword. Using the example above, only one change is needed in plugin/theplugin.vim: import autoload "../lib/getmessage.vim" Nothing in the rest of the script needs to change. However, the types will not be checked, and "../lib/getmessage.vim" is not loaded at import time; Vim only verifies that the file exists and is readable. Not even the existence of the GetMessage() function is checked until it is used. As a result, errors in the "getmessage.vim" script are detected only at runtime. You will have to decide what is more important for your script: fast startup or getting errors early. A practical strategy is to omit the autoload keyword during development and debugging so that errors are reported immediately, then add it back before distributing your plugin to improve startup performance. AUTOLOAD DIRECTORIES Another way to lazily load scripts is to `import autoload` a script without specifying any relative or absolute path, like in the following example: import autoload "monthlib.vim" Vim searches for the script in the "autoload" directories under 'runtimepath'. This means that the script must reside in an "autoload" folder. On Unix systems, one such directory is often ~/.vim/autoload. It will also search under 'packpath', under "start". When a script is imported this way, its exported symbols are referenced through a global autoload namespace rather than remaining local to the importing script. Since Vim searches every "autoload" directory in 'runtimepath', choose a unique script name. Plugin managers often add multiple directories to 'runtimepath', each of which may contain an "autoload" directory. The two forms of `import autoload` are summarized as follows: - `import autoload "foo.vim"` Vim searches 'runtimepath' for the script. Because such scripts must reside under an "autoload" directory, exported symbols are available through the global autoload namespace. - `import autoload "/some/path/foo.vim"` If the resolved path falls under an "autoload" directory, exported symbols are likewise in the global autoload namespace; otherwise they remain local to the importing script. The main advantage of accessing symbols through the global autoload namespace is that the script can be easily imported by other scripts, and symbols can be used straight away. However, this has some drawbacks when reloading a script, see vim9-reload for more info. When symbols are in script-local scope, sharing them across scripts is more involved and there is no general rule: the right approach depends on the plugin layout. Finally, when a script is imported without autoload and without path, like the following example: import "monthlib.vim" Vim will search for the script "monthlib.vim" in the import directories of 'runtimepath'. In this case, adding or removing the autoload keyword changes where Vim searches for the script. When a relative or absolute path is used, then the location does not change. ============================================================================== 52.3 Autoloading without import/export write-library-script A mechanism from before import/export is still useful and some users may find it a bit simpler. The idea is that you call a function with a special name. That function is then in an autoload script. We will call that one script a library script. The autoload mechanism is based on a function name that has "#" characters: mylib#myfunction(arg) Vim will recognize the function name by the embedded "#" character and when it is not defined yet search for the script "autoload/mylib.vim" in 'runtimepath'. That script must define the "mylib#myfunction()" function. Obviously the name "mylib" is the part before the "#" and is used as the name of the script, adding ".vim". You can put many other functions in the mylib.vim script, you are free to organize your functions in library scripts. But you must use function names where the part before the '#' matches the script name. Otherwise Vim would not know what script to load. This is where it differs from the import/export mechanism. If you get really enthusiastic and write lots of library scripts, you may want to use subdirectories. Example: netlib#ftp#read('somefile') Here the script name is taken from the function name up to the last "#". The "#" in the middle are replaced by a slash, the last one by ".vim". Thus you get "netlib/ftp.vim". For Unix the library script used for this could be: ~/.vim/autoload/netlib/ftp.vim Where the function is defined like this: def netlib#ftp#read(fname: string) # Read the file fname through ftp enddef Notice that the name the function is defined with is exactly the same as the name used for calling the function. And the part before the last '#' exactly matches the subdirectory and script name. You can use the same mechanism for variables: var weekdays = dutch#weekdays This will load the script "autoload/dutch.vim", which should contain something like: var dutch#weekdays = ['zondag', 'maandag', 'dinsdag', 'woensdag', \ 'donderdag', 'vrijdag', 'zaterdag'] Further reading: autoload. ============================================================================== 52.4 Other mechanisms to use Some may find the use of several files a hassle and prefer to keep everything together in one script. To avoid this resulting in slow startup there is a mechanism that only defines a small part and postpones the rest to when it is actually used. write-plugin-quickload The basic idea is that the plugin is loaded twice. The first time user commands and mappings are defined that offer the functionality. The second time the functions that implement the functionality are defined. It may sound surprising that quickload means loading a script twice. What we mean is that it loads quickly the first time, postponing the bulk of the script to the second time, which only happens when you actually use it. When you always use the functionality it actually gets slower! This uses a FuncUndefined autocommand. This works differently from the autoload functionality explained above. The following example shows how it's done: " Vim global plugin for demonstrating quick loading " Last Change: 2005 Feb 25 " Maintainer: Bram Moolenaar <Bram@vim.org> " License: This file is placed in the public domain. if !exists("s:did_load") command -nargs=* BNRead call BufNetRead(<f-args>) map <F19> :call BufNetWrite('something')<CR> let s:did_load = 1 exe 'au FuncUndefined BufNet* source ' .. expand('<sfile>') finish endif function BufNetRead(...) echo 'BufNetRead(' .. string(a:000) .. ')' " read functionality here endfunction function BufNetWrite(...) echo 'BufNetWrite(' .. string(a:000) .. ')' " write functionality here endfunction When the script is first loaded "s:did_load" is not set. The commands between the "if" and "endif" will be executed. This ends in a :finish command, thus the rest of the script is not executed. The second time the script is loaded "s:did_load" exists and the commands after the "endif" are executed. This defines the (possible long) BufNetRead() and BufNetWrite() functions. If you drop this script in your plugin directory Vim will execute it on startup. This is the sequence of events that happens: 1. The "BNRead" command is defined and the <F19> key is mapped when the script is sourced at startup. A FuncUndefined autocommand is defined. The ":finish" command causes the script to terminate early. 2. The user types the BNRead command or presses the <F19> key. The BufNetRead() or BufNetWrite() function will be called. 3. Vim can't find the function and triggers the FuncUndefined autocommand event. Since the pattern "BufNet*" matches the invoked function, the command "source fname" will be executed. "fname" will be equal to the name of the script, no matter where it is located, because it comes from expanding "<sfile>" (see expand()). 4. The script is sourced again, the "s:did_load" variable exists and the functions are defined. Notice that the functions that are loaded afterwards match the pattern in the FuncUndefined autocommand. You must make sure that no other plugin defines functions that match this pattern. ============================================================================== 52.5 Using a Vim9 script from legacy script source-vim9-script In some cases you have a legacy Vim script where you want to use items from a Vim9 script. For example in your .vimrc you want to initialize a plugin. The best way to do this is to use :import. For example: import 'myNicePlugin.vim' call myNicePlugin.NiceInit('today') This finds the exported function "NiceInit" in the Vim9 script file and makes it available as script-local item "myNicePlugin.NiceInit". :import always uses the script namespace, even when "s:" is not given. If "myNicePlugin.vim" was already sourced it is not sourced again. Besides avoiding putting any items in the global namespace (where name clashes can cause unexpected errors), this also means the script is sourced only once, no matter how many times items from it are imported. In some cases, e.g. for testing, you may just want to source the Vim9 script. That is OK, but then only global items will be available. The Vim9 script will have to make sure to use a unique name for these global items. Example: source ~/.vim/extra/myNicePlugin.vim call g:NicePluginTest() ============================================================================== 52.6 Vim9 examples: comment and highlight-yank plugin COMMENT PACKAGE Vim comes with a comment plugin, written in Vim9 script. comment-install Have a look at the package located at $VIMRUNTIME/pack/dist/opt/comment/ HIGHLIGHT YANK PLUGIN Vim comes with the highlight-yank plugin, written in Vim9 script hlyank-install, here is a simplified implementation: vim9script def HighlightedYank(hlgroup = 'IncSearch', duration = 300, in_visual = true) if v:event.operator ==? 'y' if !in_visual && visualmode() != null_string visualmode(1) return endif var [beg, end] = [getpos("'["), getpos("']")] var type = v:event.regtype ?? 'v' var pos = getregionpos(beg, end, {type: type, exclusive: false}) var m = matchaddpos(hlgroup, pos->mapnew((_, v) => { var col_beg = v[0][2] + v[0][3] var col_end = v[1][2] + v[1][3] + 1 return [v[0][1], col_beg, col_end - col_beg] })) var winid = win_getid() timer_start(duration, (_) => m->matchdelete(winid)) endif enddef autocmd TextYankPost * HighlightedYank() For the complete example, have a look into the package located at $VIMRUNTIME/pack/dist/opt/hlyank/ ============================================================================== Next chapter: usr_90.txt Installing Vim Copyright: see manual-copyright vim:tw=78:ts=8:noet:ft=help:norl: