pack/foo/start/foobar/plugin/foo.vim
	pack/foo/start/foobar/syntax/some.vim

From here it works like above.


Optional plugins ~
							*pack-add*
To load an optional plugin from a pack use the `:packadd` command: >
	:packadd foodebug
This searches for "pack/*/opt/foodebug" in 'packpath' and will find
~/.local/share/nvim/site/pack/foo/opt/foodebug/plugin/debugger.vim and source
it.

This could be done if some conditions are met.  For example, depending on
whether Nvim supports a feature or a dependency is missing.

You can also load an optional plugin at startup, by putting this command in
your |config|: >
	:packadd! foodebug
The extra "!" is so that the plugin isn't loaded if Nvim was started with
|--noplugin|.

It is perfectly normal for a package to only have files in the "opt"
directory.  You then need to load each plugin when you want to use it.


Where to put what ~

Since color schemes, loaded with `:colorscheme`, are found below
"pack/*/start" and "pack/*/opt", you could put them anywhere.  We recommend
you put them below "pack/*/opt", for example
"~/.config/nvim/pack/mycolors/opt/dark/colors/very_dark.vim".

Filetype plugins should go under "pack/*/start", so that they are always
found.  Unless you have more than one plugin for a file type and want to
select which one to load with `:packadd`.  E.g. depending on the compiler
version: >
	if foo_compiler_version > 34
	  packadd foo_new
	else
	  packadd foo_old
	endif

The "after" directory is most likely not useful in a package.  It's not
disallowed though.

==============================================================================
Creating Vim packages					*package-create*

This assumes you write one or more plugins that you distribute as a package.

If you have two unrelated plugins you would use two packages, so that Vim
users can choose what they include or not.  Or you can decide to use one
package with optional plugins, and tell the user to add the preferred ones with
`:packadd`.

Decide how you want to distribute the package.  You can create an archive or
you could use a repository.  An archive can be used by more users, but is a
bit harder to update to a new version.  A repository can usually be kept
up-to-date easily, but it requires a program like "git" to be available.
You can do both, github can automatically create an archive for a release.

Your directory layout would be like this:
   start/foobar/plugin/foo.vim		" always loaded, defines commands
   start/foobar/plugin/bar.vim		" always loaded, defines commands
   start/foobar/autoload/foo.vim	" loaded when foo command used
   start/foobar/doc/foo.txt		" help for foo.vim
   start/foobar/doc/tags		" help tags
   opt/fooextra/plugin/extra.vim	" optional plugin, defines commands
   opt/fooextra/autoload/extra.vim	" loaded when extra command used
   opt/fooextra/doc/extra.txt		" help for extra.vim
   opt/fooextra/doc/tags		" help tags

This allows for the user to do: >
	mkdir ~/.local/share/nvim/site/pack
	cd ~/.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