This aims to provide new developers with a clean, modular starting point for working with OCaml and its associated tools in vim. To accomplish this, we are assembling and organizing a set of appropriate plugins and configuration scripts. These include:

Design Specification

This design aims to provide a basic structure for organizing plugins in a productive way.

Consider the following directory structure<sup>1</sup>:

.vim | ---> enabled_bundles ---> available_bundles ---> enabled_snippets ---> available_snippets ---> autoload # this is where the pathogen stuff goes ---> #... etc. maybe nothing

Then I would write a simple command-line tool, probably in OCaml for consistency which would provide the user with a list of plugins and some visual cue as to which are enabled and which are not. A prompt like:

  1. ocamlspotter *
  2. omake-server -
  3. fancy-plugin-that-i-made-up -

This list would simply be generated by basically taking the diff between the enabled bundles and available bundles directories. The user would be given a prompt that allowed him/her to enable or disable plugins based on this list. This would correspond to creating a symlink from available to enabled or deleting said symlink. If the user wanted to add his/her own plugins to this structure he/she would just need to drop the bundle into available bundles. Similarly, existing stuff spread out amongst vim directories would not be clobbered.

Similarly, I would adapt this command line tool to handle "snippets" of vimscript (e.g. mappings, useful functions, etc. that would normally sit in vimrc):

  1. Dvorak mappings *
  2. Handy Lusty Explorer mappings *
  3. dlobraico's favorite mappings -

...with the idea being that users could contribute to that list in the upstream repo and then new users would have something to start with.

This command line tool would be configured through a simple sexp file that provided a list of useful places to grab bundles and snippets. E.g.:

 ((git) (
 ((hg)  (
 ((svn) (some-svn-server))
 ((zip) (random-zip-file))
 ((tar) (random-tar-file)))


1: Sharp readers will notice that this sounds a lot like the way Apache 2 handles vhost and module configs (on some systems?) i.e. sites-available and sites-enabled, modules-available and modules-enabled.