~/.local/share/nvim/site/pack
	git clone https://github.com/you/foobar.git myfoobar

Here "myfoobar" is a name that the user can choose, the only condition is that
it differs from other packages.

In your documentation you explain what the plugins do, and tell the user how
to load the optional plugin: >
	:packadd! fooextra

You could add this packadd command in one of your plugins, to be executed when
the optional plugin is needed.

Run the `:helptags` command to generate the doc/tags file.  Including this
generated file in the package means that the user can drop the package in the
pack directory and the help command works right away.  Don't forget to re-run
the command after changing the plugin help: >
	:helptags path/start/foobar/doc
	:helptags path/opt/fooextra/doc


Dependencies between plugins ~
							*packload-two-steps*
Suppose you have two plugins that depend on the same functionality. You can
put the common functionality in an autoload directory, so that it will be
found automatically.  Your package would have these files:

	pack/foo/start/one/plugin/one.vim  >
		call foolib#getit()
<	pack/foo/start/two/plugin/two.vim >
		call foolib#getit()
<	pack/foo/start/lib/autoload/foolib.vim >
		func foolib#getit()

This works, because start packages will be searched for autoload files, when
sourcing the plugins.

==============================================================================
Debugging scripts					*debug-scripts*

Besides the obvious messages that you can add to your scripts to find out what
they are doing, Vim offers a debug mode.  This allows you to step through a
sourced file or user function and set breakpoints.

NOTE: The debugging mode is far from perfect.  Debugging will have side
effects on how Vim works.  You cannot use it to debug everything.  For
example, the display is messed up by the debugging messages.

An alternative to debug mode is setting the 'verbose' option.  With a bigger
number it will give more verbose messages about what Vim is doing.


STARTING DEBUG MODE						*debug-mode*

To enter debugging mode use one of these methods:
1. Start Vim with the |-D| argument: >
	vim -D file.txt
<  Debugging will start as soon as the first vimrc file is sourced.  This is
   useful to find out what is happening when Vim is starting up.  A side
   effect is that Vim will switch the terminal mode before initialisations
   have finished, with unpredictable results.
   For a GUI-only version (Windows) the debugging will start as
   soon as the GUI window has been opened.  To make this happen early, add a
   ":gui" command in the vimrc file.
								*:debug*
2. Run a command with ":debug" prepended.  Debugging will only be done while
   this command executes.  Useful for debugging a specific script or user
   function.  And for scripts and functions used by autocommands.  Example: >
	:debug edit test.txt.gz

3. Set a breakpoint in a sourced file or user function.  You could do this in
   the command line: >
	vim -c "breakadd file */explorer.vim" .
<  This will run Vim and stop in the first line of the "explorer.vim" script.
   Breakpoints can also be set while in debugging mode.

In debugging mode every executed command is displayed before it is executed.
Comment lines, empty lines and lines that are not executed are skipped.  When
a line contains two commands, separated by "|", each command will be displayed
separately.


DEBUG MODE

Once in debugging mode, the usual Ex commands can be used.  For example, to
inspect the value of a variable: >
	echo idx
When inside a user function, this will print the value of the local variable
"idx".  Prepend "g:" to get the value of a global variable: >
	echo g:idx
All commands are executed in the context of the current function or script.
You can also set options, for example setting or resetting 'verbose' will show
what happens, but you might want to set it just before executing the lines you
are interested in: >
	:set verbose=20

Commands that require updating the screen