Home Explore Blog CI



neovim

22th chunk of `runtime/doc/usr_41.txt`
de9cba41a5692e83ff339cf99e893f0ac156ee52ff7368460000000100000fa0
 functions.
- Put the definition of your functions together in a file.  Set a global
  variable to indicate that the functions have been loaded.  When sourcing the
  file again, first unload the functions.
Example: >

	" This is the XXX package

	if exists("XXX_loaded")
	  delfun XXX_one
	  delfun XXX_two
	endif

	function XXX_one(a)
		... body of function ...
	endfun

	function XXX_two(b)
		... body of function ...
	endfun

	let XXX_loaded = 1

==============================================================================
*41.11*	Writing a 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|.


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.  And please limit the name to 8 characters, to avoid problems on
old MS-Windows systems.

A script that corrects typing mistakes could be called "typecorr.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: >

 14	iabbrev teh the
 15	iabbrev otehr other
 16	iabbrev wnat want
 17	iabbrev synchronisation
 18		\ synchronization
 19	let s:count = 4

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!


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: >

  1	" Vim global plugin for correcting typing mistakes
  2	" Last Change:	2000 Oct 15
  3	" 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: >

  4	" License:	This file is placed in the public domain.


LINE CONTINUATION, AVOIDING SIDE EFFECTS		*use-cpo-save*

In line 18 above, the line-continuation mechanism is used |line-continuation|.
Users with 'compatible' set will run into trouble here, they will get an error
message.  We can't just reset 'compatible', because that has a lot of side
effects.  To avoid this, we will set the 'cpoptions' option to its Vim default
value and restore it later.  That will allow the use of line-continuation and
make the script work for most people.  It is done like this: >

 11	let s:save_cpo = &cpo
 12	set cpo&vim
 ..
 42	let &cpo = s:save_cpo
 43	unlet s:save_cpo

We first store the old value of 'cpoptions' in the s:save_cpo variable.  At
the end of the plugin this value is restored.

Notice that a script-local variable is used |s:var|.  A global variable could
already be in use for something else.  Always use script-local variables for
things that are only used in the script.


NOT LOADING

It's 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 their own plugin they want to use.  Then the user must have

Title: Writing Vim Plugins: Naming, Body, Header, and Avoiding Side Effects
Summary
This section delves deeper into writing Vim plugins, covering aspects like choosing a descriptive and unique name, structuring the plugin's body with the actual functionality (using `iabbrev` as an example), and adding a header with essential information such as the plugin's purpose, last update date, maintainer, and licensing information. It also emphasizes the importance of handling line continuation and avoiding side effects by saving and restoring the 'cpoptions' setting using script-local variables, and preventing the plugin from loading when unwanted by checking `g:did_load_filetype_plugin`.