123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603604605606607608609610611612613614615616617618619620621622623624625626627628629630631632633634635636637638639640641642643644645646647648649650651652653654655656657658659660661662663664665666667668669670671672673674675676677678679680681682683684685686687688689690691692693694695 |
- *usr_51.txt* For Vim version 9.0. Last change: 2022 Jun 03
- VIM USER MANUAL - by Bram Moolenaar
- Write plugins
- Plugins can be used to define settings for a specific type of file, syntax
- highlighting and many other things. This chapter explains how to write the
- most common Vim plugins.
- |51.1| Writing a generic plugin
- |51.2| Writing a filetype plugin
- |51.3| Writing a compiler plugin
- |51.4| Distributing Vim scripts
- Next chapter: |usr_52.txt| Write large plugins
- Previous chapter: |usr_50.txt| Advanced Vim script writing
- Table of contents: |usr_toc.txt|
- ==============================================================================
- *51.1* Writing a generic plugin *write-plugin*
- You can write a Vim script in such a way that many people can use it. This is
- called a plugin. Vim users can drop your script in their plugin directory and
- use its features right away |add-plugin|.
- There are actually two types of plugins:
- global plugins: For all types of files.
- filetype plugins: Only for files of a specific type.
- In this section the first type is explained. Most items are also relevant for
- writing filetype plugins. The specifics for filetype plugins are in the next
- section |write-filetype-plugin|.
- We will use |Vim9| syntax here, the recommended way to write new plugins.
- Make sure the file starts with the `vim9script` command.
- NAME
- First of all you must choose a name for your plugin. The features provided
- by the plugin should be clear from its name. And it should be unlikely that
- someone else writes a plugin with the same name but which does something
- different.
- A script that corrects typing mistakes could be called "typecorrect.vim". We
- will use it here as an example.
- For the plugin to work for everybody, it should follow a few guidelines. This
- will be explained step-by-step. The complete example plugin is at the end.
- BODY
- Let's start with the body of the plugin, the lines that do the actual work: >
- 12 iabbrev teh the
- 13 iabbrev otehr other
- 14 iabbrev wnat want
- 15 iabbrev synchronisation
- 16 \ synchronization
- The actual list should be much longer, of course.
- The line numbers have only been added to explain a few things, don't put them
- in your plugin file!
- FIRST LINE
- >
- 1 vim9script noclear
- You need to use `vim9script` as the very first command. Best is to put it in
- the very first line.
- The script we are writing will have a `finish` command to bail out when it is
- loaded a second time. To avoid that the items defined in the script are lost
- the "noclear" argument is used. More info about this at |vim9-reload|.
- HEADER
- You will probably add new corrections to the plugin and soon have several
- versions lying around. And when distributing this file, people will want to
- know who wrote this wonderful plugin and where they can send remarks.
- Therefore, put a header at the top of your plugin: >
- 2 # Vim global plugin for correcting typing mistakes
- 3 # Last Change: 2021 Dec 30
- 4 # Maintainer: Bram Moolenaar <Bram@vim.org>
- About copyright and licensing: Since plugins are very useful and it's hardly
- worth restricting their distribution, please consider making your plugin
- either public domain or use the Vim |license|. A short note about this near
- the top of the plugin should be sufficient. Example: >
- 5 # License: This file is placed in the public domain.
- NOT LOADING
- It is possible that a user doesn't always want to load this plugin. Or the
- system administrator has dropped it in the system-wide plugin directory, but a
- user has his own plugin he wants to use. Then the user must have a chance to
- disable loading this specific plugin. These lines will make it possible: >
- 7 if exists("g:loaded_typecorrect")
- 8 finish
- 9 endif
- 10 g:loaded_typecorrect = 1
- This also avoids that when the script is loaded twice it would pointlessly
- redefine functions and cause trouble for autocommands that are added twice.
- The name is recommended to start with "g:loaded_" and then the file name of
- the plugin, literally. The "g:" is prepended to make the variable global, so
- that other places can check whether its functionality is available. Without
- "g:" it would be local to the script.
- Using `finish` stops Vim from reading the rest of the file, it's much quicker
- than using if-endif around the whole file, since Vim would still need to parse
- the commands to find the `endif`.
- MAPPING
- Now let's make the plugin more interesting: We will add a mapping that adds a
- correction for the word under the cursor. We could just pick a key sequence
- for this mapping, but the user might already use it for something else. To
- allow the user to define which keys a mapping in a plugin uses, the <Leader>
- item can be used: >
- 20 map <unique> <Leader>a <Plug>TypecorrAdd;
- The "<Plug>TypecorrAdd;" thing will do the work, more about that further on.
- The user can set the "g:mapleader" variable to the key sequence that he wants
- plugin mappings to start with. Thus if the user has done: >
- g:mapleader = "_"
- the mapping will define "_a". If the user didn't do this, the default value
- will be used, which is a backslash. Then a map for "\a" will be defined.
- Note that <unique> is used, this will cause an error message if the mapping
- already happened to exist. |:map-<unique>|
- But what if the user wants to define his own key sequence? We can allow that
- with this mechanism: >
- 19 if !hasmapto('<Plug>TypecorrAdd;')
- 20 map <unique> <Leader>a <Plug>TypecorrAdd;
- 21 endif
- This checks if a mapping to "<Plug>TypecorrAdd;" already exists, and only
- defines the mapping from "<Leader>a" if it doesn't. The user then has a
- chance of putting this in his vimrc file: >
- map ,c <Plug>TypecorrAdd;
- Then the mapped key sequence will be ",c" instead of "_a" or "\a".
- PIECES
- If a script gets longer, you often want to break up the work in pieces. You
- can use functions or mappings for this. But you don't want these functions
- and mappings to interfere with the ones from other scripts. For example, you
- could define a function Add(), but another script could try to define the same
- function. To avoid this, we define the function local to the script.
- Fortunately, in |Vim9| script this is the default. In a legacy script you
- would need to prefix the name with "s:".
- We will define a function that adds a new typing correction: >
- 28 def Add(from: string, correct: bool)
- 29 var to = input($"type the correction for {from}: ")
- 30 exe $":iabbrev {from} {to}"
- ...
- 34 enddef
- Now we can call the function Add() from within this script. If another
- script also defines Add(), it will be local to that script and can only
- be called from that script. There can also be a global g:Add() function,
- which is again another function.
- <SID> can be used with mappings. It generates a script ID, which identifies
- the current script. In our typing correction plugin we use it like this: >
- 22 noremap <unique> <script> <Plug>TypecorrAdd; <SID>Add
- ...
- 26 noremap <SID>Add :call <SID>Add(expand("<cword>"), true)<CR>
- Thus when a user types "\a", this sequence is invoked: >
- \a -> <Plug>TypecorrAdd; -> <SID>Add -> :call <SID>Add(...)
- If another script also maps <SID>Add, it will get another script ID and
- thus define another mapping.
- Note that instead of Add() we use <SID>Add() here. That is because the
- mapping is typed by the user, thus outside of the script context. The <SID>
- is translated to the script ID, so that Vim knows in which script to look for
- the Add() function.
- This is a bit complicated, but it's required for the plugin to work together
- with other plugins. The basic rule is that you use <SID>Add() in mappings and
- Add() in other places (the script itself, autocommands, user commands).
- We can also add a menu entry to do the same as the mapping: >
- 24 noremenu <script> Plugin.Add\ Correction <SID>Add
- The "Plugin" menu is recommended for adding menu items for plugins. In this
- case only one item is used. When adding more items, creating a submenu is
- recommended. For example, "Plugin.CVS" could be used for a plugin that offers
- CVS operations "Plugin.CVS.checkin", "Plugin.CVS.checkout", etc.
- Note that in line 28 ":noremap" is used to avoid that any other mappings cause
- trouble. Someone may have remapped ":call", for example. In line 24 we also
- use ":noremap", but we do want "<SID>Add" to be remapped. This is why
- "<script>" is used here. This only allows mappings which are local to the
- script. |:map-<script>| The same is done in line 26 for ":noremenu".
- |:menu-<script>|
- <SID> AND <Plug> *using-<Plug>*
- Both <SID> and <Plug> are used to avoid that mappings of typed keys interfere
- with mappings that are only to be used from other mappings. Note the
- difference between using <SID> and <Plug>:
- <Plug> is visible outside of the script. It is used for mappings which the
- user might want to map a key sequence to. <Plug> is a special code
- that a typed key will never produce.
- To make it very unlikely that other plugins use the same sequence of
- characters, use this structure: <Plug> scriptname mapname
- In our example the scriptname is "Typecorr" and the mapname is "Add".
- We add a semicolon as the terminator. This results in
- "<Plug>TypecorrAdd;". Only the first character of scriptname and
- mapname is uppercase, so that we can see where mapname starts.
- <SID> is the script ID, a unique identifier for a script.
- Internally Vim translates <SID> to "<SNR>123_", where "123" can be any
- number. Thus a function "<SID>Add()" will have a name "<SNR>11_Add()"
- in one script, and "<SNR>22_Add()" in another. You can see this if
- you use the ":function" command to get a list of functions. The
- translation of <SID> in mappings is exactly the same, that's how you
- can call a script-local function from a mapping.
- USER COMMAND
- Now let's add a user command to add a correction: >
- 36 if !exists(":Correct")
- 37 command -nargs=1 Correct :call Add(<q-args>, false)
- 38 endif
- The user command is defined only if no command with the same name already
- exists. Otherwise we would get an error here. Overriding the existing user
- command with ":command!" is not a good idea, this would probably make the user
- wonder why the command he defined himself doesn't work. |:command|
- If it did happen you can find out who to blame with: >
- verbose command Correct
- SCRIPT VARIABLES
- When a variable starts with "s:" it is a script variable. It can only be used
- inside a script. Outside the script it's not visible. This avoids trouble
- with using the same variable name in different scripts. The variables will be
- kept as long as Vim is running. And the same variables are used when sourcing
- the same script again. |s:var|
- The nice thing about |Vim9| script is that variables are local to the script
- by default. You can prepend "s:" if you like, but you do not need to. And
- functions in the script can also use the script variables without a prefix
- (they must be declared before the function for this to work).
- Script-local variables can also be used in functions, autocommands and user
- commands that are defined in the script. Thus they are the perfect way to
- share information between parts of your plugin, without it leaking out. In
- our example we can add a few lines to count the number of corrections: >
- 17 var count = 4
- ...
- 28 def Add(from: string, correct: bool)
- ...
- 32 count += 1
- 33 echo "you now have " .. count .. " corrections"
- 34 enddef
- "count" is declared and initialized to 4 in the script itself. When later
- the Add() function is called, it increments "count". It doesn't matter from
- where the function was called, since it has been defined in the script, it
- will use the local variables from this script.
- THE RESULT
- Here is the resulting complete example: >
- 1 vim9script noclear
- 2 # Vim global plugin for correcting typing mistakes
- 3 # Last Change: 2021 Dec 30
- 4 # Maintainer: Bram Moolenaar <Bram@vim.org>
- 5 # License: This file is placed in the public domain.
- 6
- 7 if exists("g:loaded_typecorrect")
- 8 finish
- 9 endif
- 10 g:loaded_typecorrect = 1
- 11
- 12 iabbrev teh the
- 13 iabbrev otehr other
- 14 iabbrev wnat want
- 15 iabbrev synchronisation
- 16 \ synchronization
- 17 var count = 4
- 18
- 19 if !hasmapto('<Plug>TypecorrAdd;')
- 20 map <unique> <Leader>a <Plug>TypecorrAdd;
- 21 endif
- 22 noremap <unique> <script> <Plug>TypecorrAdd; <SID>Add
- 23
- 24 noremenu <script> Plugin.Add\ Correction <SID>Add
- 25
- 26 noremap <SID>Add :call <SID>Add(expand("<cword>"), true)<CR>
- 27
- 28 def Add(from: string, correct: bool)
- 29 var to = input("type the correction for " .. from .. ": ")
- 30 exe ":iabbrev " .. from .. " " .. to
- 31 if correct | exe "normal viws\<C-R>\" \b\e" | endif
- 32 count += 1
- 33 echo "you now have " .. count .. " corrections"
- 34 enddef
- 35
- 36 if !exists(":Correct")
- 37 command -nargs=1 Correct call Add(<q-args>, false)
- 38 endif
- Line 31 wasn't explained yet. It applies the new correction to the word under
- the cursor. The |:normal| command is used to use the new abbreviation. Note
- that mappings and abbreviations are expanded here, even though the function
- was called from a mapping defined with ":noremap".
- DOCUMENTATION *write-local-help*
- It's a good idea to also write some documentation for your plugin. Especially
- when its behavior can be changed by the user. See |add-local-help| for how
- they are installed.
- Here is a simple example for a plugin help file, called "typecorrect.txt": >
- 1 *typecorrect.txt* Plugin for correcting typing mistakes
- 2
- 3 If you make typing mistakes, this plugin will have them corrected
- 4 automatically.
- 5
- 6 There are currently only a few corrections. Add your own if you like.
- 7
- 8 Mappings:
- 9 <Leader>a or <Plug>TypecorrAdd;
- 10 Add a correction for the word under the cursor.
- 11
- 12 Commands:
- 13 :Correct {word}
- 14 Add a correction for {word}.
- 15
- 16 *typecorrect-settings*
- 17 This plugin doesn't have any settings.
- The first line is actually the only one for which the format matters. It will
- be extracted from the help file to be put in the "LOCAL ADDITIONS:" section of
- help.txt |local-additions|. The first "*" must be in the first column of the
- first line. After adding your help file do ":help" and check that the entries
- line up nicely.
- You can add more tags inside ** in your help file. But be careful not to use
- existing help tags. You would probably use the name of your plugin in most of
- them, like "typecorrect-settings" in the example.
- Using references to other parts of the help in || is recommended. This makes
- it easy for the user to find associated help.
- SUMMARY *plugin-special*
- Summary of special things to use in a plugin:
- var name Variable local to the script.
- <SID> Script-ID, used for mappings and functions local to
- the script.
- hasmapto() Function to test if the user already defined a mapping
- for functionality the script offers.
- <Leader> Value of "mapleader", which the user defines as the
- keys that plugin mappings start with.
- map <unique> Give a warning if a mapping already exists.
- noremap <script> Use only mappings local to the script, not global
- mappings.
- exists(":Cmd") Check if a user command already exists.
- ==============================================================================
- *51.2* Writing a filetype plugin *write-filetype-plugin* *ftplugin*
- A filetype plugin is like a global plugin, except that it sets options and
- defines mappings for the current buffer only. See |add-filetype-plugin| for
- how this type of plugin is used.
- First read the section on global plugins above |51.1|. All that is said there
- also applies to filetype plugins. There are a few extras, which are explained
- here. The essential thing is that a filetype plugin should only have an
- effect on the current buffer.
- DISABLING
- If you are writing a filetype plugin to be used by many people, they need a
- chance to disable loading it. Put this at the top of the plugin: >
- # Only do this when not done yet for this buffer
- if exists("b:did_ftplugin")
- finish
- endif
- b:did_ftplugin = 1
- This also needs to be used to avoid that the same plugin is executed twice for
- the same buffer (happens when using an ":edit" command without arguments).
- Now users can disable loading the default plugin completely by making a
- filetype plugin with only these lines: >
- vim9script
- b:did_ftplugin = 1
- This does require that the filetype plugin directory comes before $VIMRUNTIME
- in 'runtimepath'!
- If you do want to use the default plugin, but overrule one of the settings,
- you can write the different setting in a script: >
- setlocal textwidth=70
- Now write this in the "after" directory, so that it gets sourced after the
- distributed "vim.vim" ftplugin |after-directory|. For Unix this would be
- "~/.vim/after/ftplugin/vim.vim". Note that the default plugin will have set
- "b:did_ftplugin", it is ignored here.
- OPTIONS
- To make sure the filetype plugin only affects the current buffer use the >
- setlocal
- command to set options. And only set options which are local to a buffer (see
- the help for the option to check that). When using `:setlocal` for global
- options or options local to a window, the value will change for many buffers,
- and that is not what a filetype plugin should do.
- When an option has a value that is a list of flags or items, consider using
- "+=" and "-=" to keep the existing value. Be aware that the user may have
- changed an option value already. First resetting to the default value and
- then changing it is often a good idea. Example: >
- setlocal formatoptions& formatoptions+=ro
- MAPPINGS
- To make sure mappings will only work in the current buffer use the >
- map <buffer>
- command. This needs to be combined with the two-step mapping explained above.
- An example of how to define functionality in a filetype plugin: >
- if !hasmapto('<Plug>JavaImport;')
- map <buffer> <unique> <LocalLeader>i <Plug>JavaImport;
- endif
- noremap <buffer> <unique> <Plug>JavaImport; oimport ""<Left><Esc>
- |hasmapto()| is used to check if the user has already defined a map to
- <Plug>JavaImport;. If not, then the filetype plugin defines the default
- mapping. This starts with |<LocalLeader>|, which allows the user to select
- the key(s) he wants filetype plugin mappings to start with. The default is a
- backslash.
- "<unique>" is used to give an error message if the mapping already exists or
- overlaps with an existing mapping.
- |:noremap| is used to avoid that any other mappings that the user has defined
- interferes. You might want to use ":noremap <script>" to allow remapping
- mappings defined in this script that start with <SID>.
- The user must have a chance to disable the mappings in a filetype plugin,
- without disabling everything. Here is an example of how this is done for a
- plugin for the mail filetype: >
- # Add mappings, unless the user didn't want this.
- if !exists("g:no_plugin_maps") && !exists("g:no_mail_maps")
- # Quote text by inserting "> "
- if !hasmapto('<Plug>MailQuote;')
- vmap <buffer> <LocalLeader>q <Plug>MailQuote;
- nmap <buffer> <LocalLeader>q <Plug>MailQuote;
- endif
- vnoremap <buffer> <Plug>MailQuote; :s/^/> /<CR>
- nnoremap <buffer> <Plug>MailQuote; :.,$s/^/> /<CR>
- endif
- Two global variables are used:
- |g:no_plugin_maps| disables mappings for all filetype plugins
- |g:no_mail_maps| disables mappings for the "mail" filetype
- USER COMMANDS
- To add a user command for a specific file type, so that it can only be used in
- one buffer, use the "-buffer" argument to |:command|. Example: >
- command -buffer Make make %:r.s
- VARIABLES
- A filetype plugin will be sourced for each buffer of the type it's for. Local
- script variables will be shared between all invocations. Use local buffer
- variables |b:var| if you want a variable specifically for one buffer.
- FUNCTIONS
- When defining a function, this only needs to be done once. But the filetype
- plugin will be sourced every time a file with this filetype will be opened.
- This construct makes sure the function is only defined once: >
- if !exists("*Func")
- def Func(arg)
- ...
- enddef
- endif
- <
- Don't forget to use "noclear" with the `vim9script` command to avoid that the
- function is deleted when the script is sourced a second time.
- UNDO *undo_indent* *undo_ftplugin*
- When the user does ":setfiletype xyz" the effect of the previous filetype
- should be undone. Set the b:undo_ftplugin variable to the commands that will
- undo the settings in your filetype plugin. Example: >
- b:undo_ftplugin = "setlocal fo< com< tw< commentstring<"
- \ .. "| unlet b:match_ignorecase b:match_words b:match_skip"
- Using ":setlocal" with "<" after the option name resets the option to its
- global value. That is mostly the best way to reset the option value.
- For undoing the effect of an indent script, the b:undo_indent variable should
- be set accordingly.
- Both these variables use legacy script syntax, not |Vim9| syntax.
- FILE NAME
- The filetype must be included in the file name |ftplugin-name|. Use one of
- these three forms:
- .../ftplugin/stuff.vim
- .../ftplugin/stuff_foo.vim
- .../ftplugin/stuff/bar.vim
- "stuff" is the filetype, "foo" and "bar" are arbitrary names.
- FILETYPE DETECTION *plugin-filetype*
- If your filetype is not already detected by Vim, you should create a filetype
- detection snippet in a separate file. It is usually in the form of an
- autocommand that sets the filetype when the file name matches a pattern.
- Example: >
- au BufNewFile,BufRead *.foo setlocal filetype=foofoo
- Write this single-line file as "ftdetect/foofoo.vim" in the first directory
- that appears in 'runtimepath'. For Unix that would be
- "~/.vim/ftdetect/foofoo.vim". The convention is to use the name of the
- filetype for the script name.
- You can make more complicated checks if you like, for example to inspect the
- contents of the file to recognize the language. Also see |new-filetype|.
- SUMMARY *ftplugin-special*
- Summary of special things to use in a filetype plugin:
- <LocalLeader> Value of "maplocalleader", which the user defines as
- the keys that filetype plugin mappings start with.
- map <buffer> Define a mapping local to the buffer.
- noremap <script> Only remap mappings defined in this script that start
- with <SID>.
- setlocal Set an option for the current buffer only.
- command -buffer Define a user command local to the buffer.
- exists("*s:Func") Check if a function was already defined.
- Also see |plugin-special|, the special things used for all plugins.
- ==============================================================================
- *51.3* Writing a compiler plugin *write-compiler-plugin*
- A compiler plugin sets options for use with a specific compiler. The user can
- load it with the |:compiler| command. The main use is to set the
- 'errorformat' and 'makeprg' options.
- Easiest is to have a look at examples. This command will edit all the default
- compiler plugins: >
- next $VIMRUNTIME/compiler/*.vim
- Type `:next` to go to the next plugin file.
- There are two special items about these files. First is a mechanism to allow
- a user to overrule or add to the default file. The default files start with: >
- vim9script
- if exists("g:current_compiler")
- finish
- endif
- g:current_compiler = "mine"
- When you write a compiler file and put it in your personal runtime directory
- (e.g., ~/.vim/compiler for Unix), you set the "current_compiler" variable to
- make the default file skip the settings.
- *:CompilerSet*
- The second mechanism is to use ":set" for ":compiler!" and ":setlocal" for
- ":compiler". Vim defines the ":CompilerSet" user command for this. However,
- older Vim versions don't, thus your plugin should define it then. This is an
- example: >
- if exists(":CompilerSet") != 2
- command -nargs=* CompilerSet setlocal <args>
- endif
- CompilerSet errorformat& " use the default 'errorformat'
- CompilerSet makeprg=nmake
- When you write a compiler plugin for the Vim distribution or for a system-wide
- runtime directory, use the mechanism mentioned above. When
- "current_compiler" was already set by a user plugin nothing will be done.
- When you write a compiler plugin to overrule settings from a default plugin,
- don't check "current_compiler". This plugin is supposed to be loaded
- last, thus it should be in a directory at the end of 'runtimepath'. For Unix
- that could be ~/.vim/after/compiler.
- ==============================================================================
- *51.4* Distributing Vim scripts *distribute-script*
- Vim users will look for scripts on the Vim website: http://www.vim.org.
- If you made something that is useful for others, share it!
- Another place is github. But there you need to know where to find it! The
- advantage is that most plugin managers fetch plugins from github. You'll have
- to use your favorite search engine to find them.
- Vim scripts can be used on any system. However, there might not be a tar or
- gzip command. If you want to pack files together and/or compress them the
- "zip" utility is recommended.
- For utmost portability use Vim itself to pack scripts together. This can be
- done with the Vimball utility. See |vimball|.
- It's good if you add a line to allow automatic updating. See |glvs-plugins|.
- ==============================================================================
- Next chapter: |usr_52.txt| Write large plugins
- Copyright: see |manual-copyright| vim:tw=78:ts=8:noet:ft=help:norl:
|