An overview of what belongs in each directory of a Vim plugin.

vim-plugin-directories

plugin
    naming convention: name_of_plugin.vim
    these files are sourced for all file types

doc
    naming convention: name_of_plugin.txt
    these files document the functionality of a plugin

color
    naming convention: name_of_colorscheme.vim
    these files define a colorscheme for syntax highlighting

syntax
    naming convention: filetype.vim
    these files define the operators, keywords and constructs of a language
    the syntax groups defined here are used by the colorscheme
    (much like HTML elements, ids and classes provide hooks for CSS styling)

indent
    naming convention: filetype.vim
    these files define the `indentexpr` for a language
    the `indentexpr` is used by the `=`, `o` and `O` commands

ftplugin
    naming convention: filetype.vim
    these files are sourced only for the specified filetype
    suitable for defining functionality for one particular language
    e.g. a command to build an HTML document from a markdown source

autoload
    naming convention: ???.vim
    Vim provides a mechanism to ensure that startup time isn't compromised 
    when large scripts are loaded. Functions, commands and mappings defined
    in the autoload directory are defined with an empty implementation on
    startup. It is only when these commands are invoked by the user that the
    script is sourced in full, and each command is attached to its
    implementation.
    :help autoload-functions
    :help 41.14

Yes, the folders really do matter.

You could just put everything into your vimrc, but then it would get huge. Eventually, you might decide to refactor it, moving common parts of functionality into a file in the .vim/plugins directory. Then you could publish it, and other people would be able to install your plugin, use it, and perhaps submit patches to improve it.

But once you start sharing your plugins, you probably want to write documentation to help other people to use it properly. If you create a plain text file in the .vim/doc directory, then it will automatically be added to Vim's built in help system. If you mark up your documentation with the appropriate symbols, then users will be able to run :help plugin_name to open the relevant documentation file.

Suppose that you want to add some functionality that will only apply to a particular set of files. For example, a command that compiles markdown source files, generating an HTML document. You could create such a command in your vimrc (or a plugin file), and use an autocommand to only create the appropriate mapping for particular filetypes. This is fine for simple commands, but suppose that you have a whole suite of functions that work together on a particular filetype. The syntax for defining autocommands is ugly, and your code would quickly get unmaintainable. In this case, it would make more sense to break the functions out from a global plugin (or your vimrc file) and put them in a filetype plugin instead.

The same goes for syntax and indent files. You could (I suppose) implement these in the .vim/plugin directory, and use autocommands to only apply your functions to a particular filetype. But it would be neater to simply use the appropriate folder, and have Vim look up the syntax and indent files for each filetype on demand.

What's the point of pathogen? It's difficult to describe if you aren't familiar with the traditional way of managing Vim's plugins. Suppose you want to install two plugins that look like this:

apples/
    plugin/apples.vim
    doc/apples.txt
oranges/
    autoload/oranges.vim
    plugin/oranges.vim
    doc/oranges.txt

The traditional way of installing Vim plugins is to copy these files into your .vim directory in the following places:

~/.vim/
    autoload/
        oranges.vim
    doc/
        apples.txt
        oranges.txt
    plugin/
        apples.vim
        oranges.vim

That looks neat enough. But as you install more plugins, it becomes harder to keep track of what goes where. If you decide you want to uninstall a plugin, you have to hunt down each of the individual files and delete them. Upgrading a plugin is an even bigger PITA. In this example, all of the files from each plugin are named consistently, so they obviously belong together. But some plugins don't follow consistent naming conventions.

With pathogen, all of the files for a plugin are kept in a directory together. If you wanted to load the same two plugins, you would just add them in their entirety to the .vim/bundle directory, like this:

~/.vim/
    bundle/
        apples/
            plugin/apples.vim
            doc/apples.txt
        oranges/
            autoload/oranges.vim
            plugin/oranges.vim
            doc/oranges.txt

If you decide to uninstall a plugin, you can just nuke the entire directory. If you want to upgrade, just cd to the root of the plugin, and run git pull.

That's super helpful! Thanks!! I'd love to see this linked to on vimcasts!

That's super helpful! Thanks!! I'd love to see this linked to on vimcasts!

Glad it helped. You're right, it might be worth turning this into a blog post.

It might be useful to add the "after" directory, and a note about how it contains a clone of this structure but is loaded after other scripts. In fact I'm not too sure about this myself, so an update here would be good.

+1 for after directory.

some personal opnions :)

1. :help 41.15 to check autoload functionality
2. dir color should be colors
3. add dir ftdetect compiler

Big thanks for this.

+1 for after directory.

just curious, does the same directory structure works with neovim?
I am thinking about totally ditching .vim/ direcectory and move everything to .config/nvim/.

just curious, does the same directory structure works with neovim? I am thinking about totally ditching .vim/ direcectory and move everything to .config/nvim/.

Yeah, you can do that. Check :help vimfiles to see all about it. :)