*usr_40.txt*	For Vim version 6.0j.  Last change: 2000 Oct 21

		     VIM USER MANUAL - by Bram Moolenaar
		
			      Write a Vim script


|40.1|	Introduction
|40.2|	Expressions
|40.3|	If and while
|40.4|	Using :execute
|40.5|	Functions
|40.6|	Autocommands
|40.7|	Writing a plugin
|40.8|	Writing a filetype plugin

     Next chapter: |usr_41.txt|  Make new commands
 Previous chapter: |usr_31.txt|  Exploiting the GUI
Table of contents: |usr_toc.txt|

==============================================================================
*40.1*	Introduction

used for |vimrc|
variables
:let
:unlet

==============================================================================
*40.2*	Expressions

:echo "The value of 'tabstop' is " . &ts

The |:echo| is a good way to test an expression.

==============================================================================
*40.3*	If and while

:if version >= 600
:else
:endif

==============================================================================
*40.4*	Using :execute
==============================================================================
*40.5*	Functions
==============================================================================
*40.6*	Autocommands
|autocmd-<>|
==============================================================================
*40.7*	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 plugin: For all types of files.
filetype plugin: 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 items specifiacally for filetype plugins is in
the next section |write-filetype-plugin|.


NAME

First of all you must think of 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 does something different.
And please limit the name to 8 characters, to avoid problems on old Windows
systems.  The script that corrects typing mistakes could be called
"typecorr.vim".

For the plugin to work for everybody, it should follow a few guidelines.  This
will be explained step-by-step.  The complete exmple plugin is at the end.


BODY

Let's start with the body of the plugin, the lines that do the actual work.
The actual list should be much longer, of course. >

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

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 have several versions
laying 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>


LINE CONTINUATION, AVOIDING SIDE EFFECTS

In line 17 above, the line-continuation mechanism is used |line-continuation|.
Users with 'compatible' set will run into trouble here, they will get an error
message.  To avoid this, we will make the 'cpoptions' variable empty.  But the
user doesn't want this option to change, thus we need to restore it.  That can
be done like this: >

 10	let s:save_cpo = &cpo
 11	set cpo=

 41	let &cpo = 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.

Note 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 to
avoid problems.


NOT LOADING

It's possible that a user doesn't always want to load this plugin.  Or tha a
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.  This will do it: >

  5	if exists("loaded_typecorr")
  6	  finish
  7	endif
  8	let loaded_typecorr = 1

This also avoids that when the script is loaded twice it would cause error
messages for redefining functions and cause trouble for autocommands that are
added twice.

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

 21	  map <unique> <Leader>a  <Plug>TypecorrAdd

The "<Plug>TypecorrAdd" thing will do the work, more about that further on.

The user can set the "mapleader" variable to the key sequence that he wants
this mapping to start with.  Thus if the user has done: >

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

 20	if !hasmapto('<Plug>TypecorrAdd')
 21	  map <unique> <Leader>a  <Plug>TypecorrAdd
 22	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 won't contain an "a" at all.


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, a script-ID is used to make the functions and
mappings local to the script. |<SID>|

We will define a function that adds a new typing correction: >

 29	function <SID>Add(from, correct)
 30	  let to = input("type the correction for " . a:from . ": ")
 31	  exe ":iabbrev " . a:from . " " . to

 35	endfunction

Now we can call the function <SID>Add() from within this script.  If another
script also defines <SID>Add(), it will be local to that script and can only
be called from the script it was defined in.

<SID> can be used in the same way for mappings.  In our typing correction
plugin we use it like this: >

 23	noremap <unique> <script> <Plug>TypecorrAdd  <SID>Add

 27	noremap <SID>Add  :call <SID>Add(expand("<cword>"), 1)<CR>

Thus when a user types "\a", this sequence is invoked: >

	\a  ->  <Plug>TypecorrAdd  ->  <SID>Add  ->  :call <SID>Add()

This is a bit complicated, but it's required for the plugin to work together
with other plugins.

Now we can also add a menu entry to do the same as the mapping: >

 25	noremenu <script> Tools.Add\ Correction      <SID>Add

Note that in line 27 ":noremap" is used to avoid that any other mappings cause
trouble.  Someone may have remapped ":call", for example.  In line 23 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 25 for ":noremenu".
|:menu-<script>|


<SID> AND <Plug>

Both <SID> and <Plug> are used to avoid that mappings of typed keys interferes
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".
	This results in "<Plug>TypecorrAdd".  Only the first character of
	scriptname and mapname is upper case, so that we can see where mapname
	starts.

<SID>	is local to the script.  It is also used for function names.
	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: >

 37	if !exists(":Correct")
 38	  command -nargs=1  Correct  :call <SID>Add(<q-args>, 0)
 39	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 his command doesn't work.  |:command|


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 fun is that these variables can also be used in functions, mappings,
autocommands and user functions that are defined in the script.  In our
example we can add a few lines to count the number of corrections: >

 18	let s:count = 4

 29	function <SID>Add(from, correct)

 33	  let s:count = s:count + 1
 34	  echo s:count . " corrections now"
 35	endfunction

First s:count is initialized to 4 in the script itself.  When later the
<SID>Add() function is called, it increments s: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	" Vim global plugin for correcting typing mistakes
  2	" Last Change: 2000 Oct 15
  3	" Maintainer: Bram Moolenaar <Bram@vim.org>
  4
  5	if exists("loaded_typecorr")
  6	  finish
  7	endif
  8	let loaded_typecorr = 1
  9
 10	let s:save_cpo = &cpo
 11	set cpo=
 12
 13	iabbrev teh the
 14	iabbrev otehr other
 15	iabbrev wnat want
 16	iabbrev synchronisation
 17		\ synchronization
 18	let s:count = 4
 19
 20	if !hasmapto('<Plug>TypecorrAdd')
 21	  map <unique> <Leader>a  <Plug>TypecorrAdd
 22	endif
 23	noremap <unique> <script> <Plug>TypecorrAdd  <SID>Add
 24
 25	noremenu <script> Tools.Add\ Correction      <SID>Add
 26
 27	noremap <SID>Add  :call <SID>Add(expand("<cword>"), 1)<CR>
 28
 29	function <SID>Add(from, correct)
 30	  let to = input("type the correction for " . a:from . ": ")
 31	  exe ":iabbrev " . a:from . " " . to
 32	  if a:correct | exe "normal viws\<C-R>\" \b\e" | endif
 33	  let s:count = s:count + 1
 34	  echo s:count . " corrections now"
 35	endfunction
 36
 37	if !exists(":Correct")
 38	  command -nargs=1  Correct  :call <SID>Add(<q-args>, 0)
 39	endif
 40
 41	let &cpo = s:save_cpo

Line 32 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 "typecorr.txt": >

  1	*typecorr.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							*typecorr-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.  The first "*" must be in the first column of the first line.

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

s:name			Variables 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 doesn't exist yet.

==============================================================================
*40.8*	Writing a filetype plugin		*write-filetype-plugin*

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 |40.7|.  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

On the other hand, if you are writing a filetype plugin for your personal use,
and you don't want the default plugin to be loaded for this specific filetype,
add this to your plugin: >

	let b:did_ftplugin = 1


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 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 funcionality 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("no_plugin_maps") && !exists("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:
no_plugin_maps		disables mappings for all filetype plugins
no_mail_maps		disables mappings for a specific 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 |s:var| 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 make sure the function is only defined once: >

	if !exists("*<SID>Func")
	  function <SID>Func(arg)
	    ...
	  endfunction
	endif
<

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("*<SID>Func")	Check if a function was already defined.

Also see |plugin-special|, the special things used for all plugins.

==============================================================================
 vim:tw=78:
