usr_51.txt 25 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603604605606607608609610611612613614615616617618619620621622623624625626627628629630631632633634635636637638639640641642643644645646647648649650651652653654655656657658659660661662663664665666667668669670671672673674675676677678679680681682683684685686687688689690691692693694695
  1. *usr_51.txt* For Vim version 9.0. Last change: 2022 Jun 03
  2. VIM USER MANUAL - by Bram Moolenaar
  3. Write plugins
  4. Plugins can be used to define settings for a specific type of file, syntax
  5. highlighting and many other things. This chapter explains how to write the
  6. most common Vim plugins.
  7. |51.1| Writing a generic plugin
  8. |51.2| Writing a filetype plugin
  9. |51.3| Writing a compiler plugin
  10. |51.4| Distributing Vim scripts
  11. Next chapter: |usr_52.txt| Write large plugins
  12. Previous chapter: |usr_50.txt| Advanced Vim script writing
  13. Table of contents: |usr_toc.txt|
  14. ==============================================================================
  15. *51.1* Writing a generic plugin *write-plugin*
  16. You can write a Vim script in such a way that many people can use it. This is
  17. called a plugin. Vim users can drop your script in their plugin directory and
  18. use its features right away |add-plugin|.
  19. There are actually two types of plugins:
  20. global plugins: For all types of files.
  21. filetype plugins: Only for files of a specific type.
  22. In this section the first type is explained. Most items are also relevant for
  23. writing filetype plugins. The specifics for filetype plugins are in the next
  24. section |write-filetype-plugin|.
  25. We will use |Vim9| syntax here, the recommended way to write new plugins.
  26. Make sure the file starts with the `vim9script` command.
  27. NAME
  28. First of all you must choose a name for your plugin. The features provided
  29. by the plugin should be clear from its name. And it should be unlikely that
  30. someone else writes a plugin with the same name but which does something
  31. different.
  32. A script that corrects typing mistakes could be called "typecorrect.vim". We
  33. will use it here as an example.
  34. For the plugin to work for everybody, it should follow a few guidelines. This
  35. will be explained step-by-step. The complete example plugin is at the end.
  36. BODY
  37. Let's start with the body of the plugin, the lines that do the actual work: >
  38. 12 iabbrev teh the
  39. 13 iabbrev otehr other
  40. 14 iabbrev wnat want
  41. 15 iabbrev synchronisation
  42. 16 \ synchronization
  43. The actual list should be much longer, of course.
  44. The line numbers have only been added to explain a few things, don't put them
  45. in your plugin file!
  46. FIRST LINE
  47. >
  48. 1 vim9script noclear
  49. You need to use `vim9script` as the very first command. Best is to put it in
  50. the very first line.
  51. The script we are writing will have a `finish` command to bail out when it is
  52. loaded a second time. To avoid that the items defined in the script are lost
  53. the "noclear" argument is used. More info about this at |vim9-reload|.
  54. HEADER
  55. You will probably add new corrections to the plugin and soon have several
  56. versions lying around. And when distributing this file, people will want to
  57. know who wrote this wonderful plugin and where they can send remarks.
  58. Therefore, put a header at the top of your plugin: >
  59. 2 # Vim global plugin for correcting typing mistakes
  60. 3 # Last Change: 2021 Dec 30
  61. 4 # Maintainer: Bram Moolenaar <Bram@vim.org>
  62. About copyright and licensing: Since plugins are very useful and it's hardly
  63. worth restricting their distribution, please consider making your plugin
  64. either public domain or use the Vim |license|. A short note about this near
  65. the top of the plugin should be sufficient. Example: >
  66. 5 # License: This file is placed in the public domain.
  67. NOT LOADING
  68. It is possible that a user doesn't always want to load this plugin. Or the
  69. system administrator has dropped it in the system-wide plugin directory, but a
  70. user has his own plugin he wants to use. Then the user must have a chance to
  71. disable loading this specific plugin. These lines will make it possible: >
  72. 7 if exists("g:loaded_typecorrect")
  73. 8 finish
  74. 9 endif
  75. 10 g:loaded_typecorrect = 1
  76. This also avoids that when the script is loaded twice it would pointlessly
  77. redefine functions and cause trouble for autocommands that are added twice.
  78. The name is recommended to start with "g:loaded_" and then the file name of
  79. the plugin, literally. The "g:" is prepended to make the variable global, so
  80. that other places can check whether its functionality is available. Without
  81. "g:" it would be local to the script.
  82. Using `finish` stops Vim from reading the rest of the file, it's much quicker
  83. than using if-endif around the whole file, since Vim would still need to parse
  84. the commands to find the `endif`.
  85. MAPPING
  86. Now let's make the plugin more interesting: We will add a mapping that adds a
  87. correction for the word under the cursor. We could just pick a key sequence
  88. for this mapping, but the user might already use it for something else. To
  89. allow the user to define which keys a mapping in a plugin uses, the <Leader>
  90. item can be used: >
  91. 20 map <unique> <Leader>a <Plug>TypecorrAdd;
  92. The "<Plug>TypecorrAdd;" thing will do the work, more about that further on.
  93. The user can set the "g:mapleader" variable to the key sequence that he wants
  94. plugin mappings to start with. Thus if the user has done: >
  95. g:mapleader = "_"
  96. the mapping will define "_a". If the user didn't do this, the default value
  97. will be used, which is a backslash. Then a map for "\a" will be defined.
  98. Note that <unique> is used, this will cause an error message if the mapping
  99. already happened to exist. |:map-<unique>|
  100. But what if the user wants to define his own key sequence? We can allow that
  101. with this mechanism: >
  102. 19 if !hasmapto('<Plug>TypecorrAdd;')
  103. 20 map <unique> <Leader>a <Plug>TypecorrAdd;
  104. 21 endif
  105. This checks if a mapping to "<Plug>TypecorrAdd;" already exists, and only
  106. defines the mapping from "<Leader>a" if it doesn't. The user then has a
  107. chance of putting this in his vimrc file: >
  108. map ,c <Plug>TypecorrAdd;
  109. Then the mapped key sequence will be ",c" instead of "_a" or "\a".
  110. PIECES
  111. If a script gets longer, you often want to break up the work in pieces. You
  112. can use functions or mappings for this. But you don't want these functions
  113. and mappings to interfere with the ones from other scripts. For example, you
  114. could define a function Add(), but another script could try to define the same
  115. function. To avoid this, we define the function local to the script.
  116. Fortunately, in |Vim9| script this is the default. In a legacy script you
  117. would need to prefix the name with "s:".
  118. We will define a function that adds a new typing correction: >
  119. 28 def Add(from: string, correct: bool)
  120. 29 var to = input($"type the correction for {from}: ")
  121. 30 exe $":iabbrev {from} {to}"
  122. ...
  123. 34 enddef
  124. Now we can call the function Add() from within this script. If another
  125. script also defines Add(), it will be local to that script and can only
  126. be called from that script. There can also be a global g:Add() function,
  127. which is again another function.
  128. <SID> can be used with mappings. It generates a script ID, which identifies
  129. the current script. In our typing correction plugin we use it like this: >
  130. 22 noremap <unique> <script> <Plug>TypecorrAdd; <SID>Add
  131. ...
  132. 26 noremap <SID>Add :call <SID>Add(expand("<cword>"), true)<CR>
  133. Thus when a user types "\a", this sequence is invoked: >
  134. \a -> <Plug>TypecorrAdd; -> <SID>Add -> :call <SID>Add(...)
  135. If another script also maps <SID>Add, it will get another script ID and
  136. thus define another mapping.
  137. Note that instead of Add() we use <SID>Add() here. That is because the
  138. mapping is typed by the user, thus outside of the script context. The <SID>
  139. is translated to the script ID, so that Vim knows in which script to look for
  140. the Add() function.
  141. This is a bit complicated, but it's required for the plugin to work together
  142. with other plugins. The basic rule is that you use <SID>Add() in mappings and
  143. Add() in other places (the script itself, autocommands, user commands).
  144. We can also add a menu entry to do the same as the mapping: >
  145. 24 noremenu <script> Plugin.Add\ Correction <SID>Add
  146. The "Plugin" menu is recommended for adding menu items for plugins. In this
  147. case only one item is used. When adding more items, creating a submenu is
  148. recommended. For example, "Plugin.CVS" could be used for a plugin that offers
  149. CVS operations "Plugin.CVS.checkin", "Plugin.CVS.checkout", etc.
  150. Note that in line 28 ":noremap" is used to avoid that any other mappings cause
  151. trouble. Someone may have remapped ":call", for example. In line 24 we also
  152. use ":noremap", but we do want "<SID>Add" to be remapped. This is why
  153. "<script>" is used here. This only allows mappings which are local to the
  154. script. |:map-<script>| The same is done in line 26 for ":noremenu".
  155. |:menu-<script>|
  156. <SID> AND <Plug> *using-<Plug>*
  157. Both <SID> and <Plug> are used to avoid that mappings of typed keys interfere
  158. with mappings that are only to be used from other mappings. Note the
  159. difference between using <SID> and <Plug>:
  160. <Plug> is visible outside of the script. It is used for mappings which the
  161. user might want to map a key sequence to. <Plug> is a special code
  162. that a typed key will never produce.
  163. To make it very unlikely that other plugins use the same sequence of
  164. characters, use this structure: <Plug> scriptname mapname
  165. In our example the scriptname is "Typecorr" and the mapname is "Add".
  166. We add a semicolon as the terminator. This results in
  167. "<Plug>TypecorrAdd;". Only the first character of scriptname and
  168. mapname is uppercase, so that we can see where mapname starts.
  169. <SID> is the script ID, a unique identifier for a script.
  170. Internally Vim translates <SID> to "<SNR>123_", where "123" can be any
  171. number. Thus a function "<SID>Add()" will have a name "<SNR>11_Add()"
  172. in one script, and "<SNR>22_Add()" in another. You can see this if
  173. you use the ":function" command to get a list of functions. The
  174. translation of <SID> in mappings is exactly the same, that's how you
  175. can call a script-local function from a mapping.
  176. USER COMMAND
  177. Now let's add a user command to add a correction: >
  178. 36 if !exists(":Correct")
  179. 37 command -nargs=1 Correct :call Add(<q-args>, false)
  180. 38 endif
  181. The user command is defined only if no command with the same name already
  182. exists. Otherwise we would get an error here. Overriding the existing user
  183. command with ":command!" is not a good idea, this would probably make the user
  184. wonder why the command he defined himself doesn't work. |:command|
  185. If it did happen you can find out who to blame with: >
  186. verbose command Correct
  187. SCRIPT VARIABLES
  188. When a variable starts with "s:" it is a script variable. It can only be used
  189. inside a script. Outside the script it's not visible. This avoids trouble
  190. with using the same variable name in different scripts. The variables will be
  191. kept as long as Vim is running. And the same variables are used when sourcing
  192. the same script again. |s:var|
  193. The nice thing about |Vim9| script is that variables are local to the script
  194. by default. You can prepend "s:" if you like, but you do not need to. And
  195. functions in the script can also use the script variables without a prefix
  196. (they must be declared before the function for this to work).
  197. Script-local variables can also be used in functions, autocommands and user
  198. commands that are defined in the script. Thus they are the perfect way to
  199. share information between parts of your plugin, without it leaking out. In
  200. our example we can add a few lines to count the number of corrections: >
  201. 17 var count = 4
  202. ...
  203. 28 def Add(from: string, correct: bool)
  204. ...
  205. 32 count += 1
  206. 33 echo "you now have " .. count .. " corrections"
  207. 34 enddef
  208. "count" is declared and initialized to 4 in the script itself. When later
  209. the Add() function is called, it increments "count". It doesn't matter from
  210. where the function was called, since it has been defined in the script, it
  211. will use the local variables from this script.
  212. THE RESULT
  213. Here is the resulting complete example: >
  214. 1 vim9script noclear
  215. 2 # Vim global plugin for correcting typing mistakes
  216. 3 # Last Change: 2021 Dec 30
  217. 4 # Maintainer: Bram Moolenaar <Bram@vim.org>
  218. 5 # License: This file is placed in the public domain.
  219. 6
  220. 7 if exists("g:loaded_typecorrect")
  221. 8 finish
  222. 9 endif
  223. 10 g:loaded_typecorrect = 1
  224. 11
  225. 12 iabbrev teh the
  226. 13 iabbrev otehr other
  227. 14 iabbrev wnat want
  228. 15 iabbrev synchronisation
  229. 16 \ synchronization
  230. 17 var count = 4
  231. 18
  232. 19 if !hasmapto('<Plug>TypecorrAdd;')
  233. 20 map <unique> <Leader>a <Plug>TypecorrAdd;
  234. 21 endif
  235. 22 noremap <unique> <script> <Plug>TypecorrAdd; <SID>Add
  236. 23
  237. 24 noremenu <script> Plugin.Add\ Correction <SID>Add
  238. 25
  239. 26 noremap <SID>Add :call <SID>Add(expand("<cword>"), true)<CR>
  240. 27
  241. 28 def Add(from: string, correct: bool)
  242. 29 var to = input("type the correction for " .. from .. ": ")
  243. 30 exe ":iabbrev " .. from .. " " .. to
  244. 31 if correct | exe "normal viws\<C-R>\" \b\e" | endif
  245. 32 count += 1
  246. 33 echo "you now have " .. count .. " corrections"
  247. 34 enddef
  248. 35
  249. 36 if !exists(":Correct")
  250. 37 command -nargs=1 Correct call Add(<q-args>, false)
  251. 38 endif
  252. Line 31 wasn't explained yet. It applies the new correction to the word under
  253. the cursor. The |:normal| command is used to use the new abbreviation. Note
  254. that mappings and abbreviations are expanded here, even though the function
  255. was called from a mapping defined with ":noremap".
  256. DOCUMENTATION *write-local-help*
  257. It's a good idea to also write some documentation for your plugin. Especially
  258. when its behavior can be changed by the user. See |add-local-help| for how
  259. they are installed.
  260. Here is a simple example for a plugin help file, called "typecorrect.txt": >
  261. 1 *typecorrect.txt* Plugin for correcting typing mistakes
  262. 2
  263. 3 If you make typing mistakes, this plugin will have them corrected
  264. 4 automatically.
  265. 5
  266. 6 There are currently only a few corrections. Add your own if you like.
  267. 7
  268. 8 Mappings:
  269. 9 <Leader>a or <Plug>TypecorrAdd;
  270. 10 Add a correction for the word under the cursor.
  271. 11
  272. 12 Commands:
  273. 13 :Correct {word}
  274. 14 Add a correction for {word}.
  275. 15
  276. 16 *typecorrect-settings*
  277. 17 This plugin doesn't have any settings.
  278. The first line is actually the only one for which the format matters. It will
  279. be extracted from the help file to be put in the "LOCAL ADDITIONS:" section of
  280. help.txt |local-additions|. The first "*" must be in the first column of the
  281. first line. After adding your help file do ":help" and check that the entries
  282. line up nicely.
  283. You can add more tags inside ** in your help file. But be careful not to use
  284. existing help tags. You would probably use the name of your plugin in most of
  285. them, like "typecorrect-settings" in the example.
  286. Using references to other parts of the help in || is recommended. This makes
  287. it easy for the user to find associated help.
  288. SUMMARY *plugin-special*
  289. Summary of special things to use in a plugin:
  290. var name Variable local to the script.
  291. <SID> Script-ID, used for mappings and functions local to
  292. the script.
  293. hasmapto() Function to test if the user already defined a mapping
  294. for functionality the script offers.
  295. <Leader> Value of "mapleader", which the user defines as the
  296. keys that plugin mappings start with.
  297. map <unique> Give a warning if a mapping already exists.
  298. noremap <script> Use only mappings local to the script, not global
  299. mappings.
  300. exists(":Cmd") Check if a user command already exists.
  301. ==============================================================================
  302. *51.2* Writing a filetype plugin *write-filetype-plugin* *ftplugin*
  303. A filetype plugin is like a global plugin, except that it sets options and
  304. defines mappings for the current buffer only. See |add-filetype-plugin| for
  305. how this type of plugin is used.
  306. First read the section on global plugins above |51.1|. All that is said there
  307. also applies to filetype plugins. There are a few extras, which are explained
  308. here. The essential thing is that a filetype plugin should only have an
  309. effect on the current buffer.
  310. DISABLING
  311. If you are writing a filetype plugin to be used by many people, they need a
  312. chance to disable loading it. Put this at the top of the plugin: >
  313. # Only do this when not done yet for this buffer
  314. if exists("b:did_ftplugin")
  315. finish
  316. endif
  317. b:did_ftplugin = 1
  318. This also needs to be used to avoid that the same plugin is executed twice for
  319. the same buffer (happens when using an ":edit" command without arguments).
  320. Now users can disable loading the default plugin completely by making a
  321. filetype plugin with only these lines: >
  322. vim9script
  323. b:did_ftplugin = 1
  324. This does require that the filetype plugin directory comes before $VIMRUNTIME
  325. in 'runtimepath'!
  326. If you do want to use the default plugin, but overrule one of the settings,
  327. you can write the different setting in a script: >
  328. setlocal textwidth=70
  329. Now write this in the "after" directory, so that it gets sourced after the
  330. distributed "vim.vim" ftplugin |after-directory|. For Unix this would be
  331. "~/.vim/after/ftplugin/vim.vim". Note that the default plugin will have set
  332. "b:did_ftplugin", it is ignored here.
  333. OPTIONS
  334. To make sure the filetype plugin only affects the current buffer use the >
  335. setlocal
  336. command to set options. And only set options which are local to a buffer (see
  337. the help for the option to check that). When using `:setlocal` for global
  338. options or options local to a window, the value will change for many buffers,
  339. and that is not what a filetype plugin should do.
  340. When an option has a value that is a list of flags or items, consider using
  341. "+=" and "-=" to keep the existing value. Be aware that the user may have
  342. changed an option value already. First resetting to the default value and
  343. then changing it is often a good idea. Example: >
  344. setlocal formatoptions& formatoptions+=ro
  345. MAPPINGS
  346. To make sure mappings will only work in the current buffer use the >
  347. map <buffer>
  348. command. This needs to be combined with the two-step mapping explained above.
  349. An example of how to define functionality in a filetype plugin: >
  350. if !hasmapto('<Plug>JavaImport;')
  351. map <buffer> <unique> <LocalLeader>i <Plug>JavaImport;
  352. endif
  353. noremap <buffer> <unique> <Plug>JavaImport; oimport ""<Left><Esc>
  354. |hasmapto()| is used to check if the user has already defined a map to
  355. <Plug>JavaImport;. If not, then the filetype plugin defines the default
  356. mapping. This starts with |<LocalLeader>|, which allows the user to select
  357. the key(s) he wants filetype plugin mappings to start with. The default is a
  358. backslash.
  359. "<unique>" is used to give an error message if the mapping already exists or
  360. overlaps with an existing mapping.
  361. |:noremap| is used to avoid that any other mappings that the user has defined
  362. interferes. You might want to use ":noremap <script>" to allow remapping
  363. mappings defined in this script that start with <SID>.
  364. The user must have a chance to disable the mappings in a filetype plugin,
  365. without disabling everything. Here is an example of how this is done for a
  366. plugin for the mail filetype: >
  367. # Add mappings, unless the user didn't want this.
  368. if !exists("g:no_plugin_maps") && !exists("g:no_mail_maps")
  369. # Quote text by inserting "> "
  370. if !hasmapto('<Plug>MailQuote;')
  371. vmap <buffer> <LocalLeader>q <Plug>MailQuote;
  372. nmap <buffer> <LocalLeader>q <Plug>MailQuote;
  373. endif
  374. vnoremap <buffer> <Plug>MailQuote; :s/^/> /<CR>
  375. nnoremap <buffer> <Plug>MailQuote; :.,$s/^/> /<CR>
  376. endif
  377. Two global variables are used:
  378. |g:no_plugin_maps| disables mappings for all filetype plugins
  379. |g:no_mail_maps| disables mappings for the "mail" filetype
  380. USER COMMANDS
  381. To add a user command for a specific file type, so that it can only be used in
  382. one buffer, use the "-buffer" argument to |:command|. Example: >
  383. command -buffer Make make %:r.s
  384. VARIABLES
  385. A filetype plugin will be sourced for each buffer of the type it's for. Local
  386. script variables will be shared between all invocations. Use local buffer
  387. variables |b:var| if you want a variable specifically for one buffer.
  388. FUNCTIONS
  389. When defining a function, this only needs to be done once. But the filetype
  390. plugin will be sourced every time a file with this filetype will be opened.
  391. This construct makes sure the function is only defined once: >
  392. if !exists("*Func")
  393. def Func(arg)
  394. ...
  395. enddef
  396. endif
  397. <
  398. Don't forget to use "noclear" with the `vim9script` command to avoid that the
  399. function is deleted when the script is sourced a second time.
  400. UNDO *undo_indent* *undo_ftplugin*
  401. When the user does ":setfiletype xyz" the effect of the previous filetype
  402. should be undone. Set the b:undo_ftplugin variable to the commands that will
  403. undo the settings in your filetype plugin. Example: >
  404. b:undo_ftplugin = "setlocal fo< com< tw< commentstring<"
  405. \ .. "| unlet b:match_ignorecase b:match_words b:match_skip"
  406. Using ":setlocal" with "<" after the option name resets the option to its
  407. global value. That is mostly the best way to reset the option value.
  408. For undoing the effect of an indent script, the b:undo_indent variable should
  409. be set accordingly.
  410. Both these variables use legacy script syntax, not |Vim9| syntax.
  411. FILE NAME
  412. The filetype must be included in the file name |ftplugin-name|. Use one of
  413. these three forms:
  414. .../ftplugin/stuff.vim
  415. .../ftplugin/stuff_foo.vim
  416. .../ftplugin/stuff/bar.vim
  417. "stuff" is the filetype, "foo" and "bar" are arbitrary names.
  418. FILETYPE DETECTION *plugin-filetype*
  419. If your filetype is not already detected by Vim, you should create a filetype
  420. detection snippet in a separate file. It is usually in the form of an
  421. autocommand that sets the filetype when the file name matches a pattern.
  422. Example: >
  423. au BufNewFile,BufRead *.foo setlocal filetype=foofoo
  424. Write this single-line file as "ftdetect/foofoo.vim" in the first directory
  425. that appears in 'runtimepath'. For Unix that would be
  426. "~/.vim/ftdetect/foofoo.vim". The convention is to use the name of the
  427. filetype for the script name.
  428. You can make more complicated checks if you like, for example to inspect the
  429. contents of the file to recognize the language. Also see |new-filetype|.
  430. SUMMARY *ftplugin-special*
  431. Summary of special things to use in a filetype plugin:
  432. <LocalLeader> Value of "maplocalleader", which the user defines as
  433. the keys that filetype plugin mappings start with.
  434. map <buffer> Define a mapping local to the buffer.
  435. noremap <script> Only remap mappings defined in this script that start
  436. with <SID>.
  437. setlocal Set an option for the current buffer only.
  438. command -buffer Define a user command local to the buffer.
  439. exists("*s:Func") Check if a function was already defined.
  440. Also see |plugin-special|, the special things used for all plugins.
  441. ==============================================================================
  442. *51.3* Writing a compiler plugin *write-compiler-plugin*
  443. A compiler plugin sets options for use with a specific compiler. The user can
  444. load it with the |:compiler| command. The main use is to set the
  445. 'errorformat' and 'makeprg' options.
  446. Easiest is to have a look at examples. This command will edit all the default
  447. compiler plugins: >
  448. next $VIMRUNTIME/compiler/*.vim
  449. Type `:next` to go to the next plugin file.
  450. There are two special items about these files. First is a mechanism to allow
  451. a user to overrule or add to the default file. The default files start with: >
  452. vim9script
  453. if exists("g:current_compiler")
  454. finish
  455. endif
  456. g:current_compiler = "mine"
  457. When you write a compiler file and put it in your personal runtime directory
  458. (e.g., ~/.vim/compiler for Unix), you set the "current_compiler" variable to
  459. make the default file skip the settings.
  460. *:CompilerSet*
  461. The second mechanism is to use ":set" for ":compiler!" and ":setlocal" for
  462. ":compiler". Vim defines the ":CompilerSet" user command for this. However,
  463. older Vim versions don't, thus your plugin should define it then. This is an
  464. example: >
  465. if exists(":CompilerSet") != 2
  466. command -nargs=* CompilerSet setlocal <args>
  467. endif
  468. CompilerSet errorformat& " use the default 'errorformat'
  469. CompilerSet makeprg=nmake
  470. When you write a compiler plugin for the Vim distribution or for a system-wide
  471. runtime directory, use the mechanism mentioned above. When
  472. "current_compiler" was already set by a user plugin nothing will be done.
  473. When you write a compiler plugin to overrule settings from a default plugin,
  474. don't check "current_compiler". This plugin is supposed to be loaded
  475. last, thus it should be in a directory at the end of 'runtimepath'. For Unix
  476. that could be ~/.vim/after/compiler.
  477. ==============================================================================
  478. *51.4* Distributing Vim scripts *distribute-script*
  479. Vim users will look for scripts on the Vim website: http://www.vim.org.
  480. If you made something that is useful for others, share it!
  481. Another place is github. But there you need to know where to find it! The
  482. advantage is that most plugin managers fetch plugins from github. You'll have
  483. to use your favorite search engine to find them.
  484. Vim scripts can be used on any system. However, there might not be a tar or
  485. gzip command. If you want to pack files together and/or compress them the
  486. "zip" utility is recommended.
  487. For utmost portability use Vim itself to pack scripts together. This can be
  488. done with the Vimball utility. See |vimball|.
  489. It's good if you add a line to allow automatic updating. See |glvs-plugins|.
  490. ==============================================================================
  491. Next chapter: |usr_52.txt| Write large plugins
  492. Copyright: see |manual-copyright| vim:tw=78:ts=8:noet:ft=help:norl: