Please use plugins/packages instead of modifying the editor configs directly

[edwintorok]

Idea

Make a difference between the minimal settings required to load the Vim/Emacs extensions, and setting up reasonable defaults for OCaml:

• have one plugin for Vim and one for Emacs that sets up the editor in such a way that it autoloads further plugins from the opam switch
• this plugin would also set up integration with other packages (syntastic+merlin for Vim, or {company-mode,auto-complete}+merlin)
• this plugin should be distributed in the normal way that other Vim/Emacs plugins are distributed (a github repo for Vim, an ELPA/MELPA/marmale package for Emacs)
  • opam-user-setup's job would have a way to automatically modify .vimrc/.emacs to load these from .opam if the user doesn't want to mess with plugins
  • it should also have a second mode that sets up a .vimrc/.emacs from scratch with some reasonable defaults, for example if you use this to setup a Docker container or Vagrant VM, but this shouldn't be used if the user already has a .vimrc/.emacs/.emacs.d

This way you can still customize your .vimrc/.emacs/.emacs.d in addition to the minimal settings required to get a reasonable OCaml editing experience. For example things such as colorschemes, indentation settings, etc. is probably something the user wants to customize in addition to the settings provided by opam-user-setup.

Rationale

I use Pathogen to manage Vim plugins, and then adding a plugin is as simple as git clone (or submodule add-ing) something to my ~/.vim/bundle/, and they get autoloaded on startup. There isn't a universal package manager for Vim though (some may use Vundle, Neobundle, vim-addon-manager, ... etc.) but they are all based on the idea of adding subdirs to the runtimepath.

I think there should be one Vim plugin that sets up Vim's runtime path to include stuff from ~/.opam//share/vim, and ~/.opam//share//vim, and also various settings for other plugins (syntastic, neocomplcache, etc.). Then all the user has to do is to install this plugin the usual way, and whenever an opam package is installed that extends vim in some way it automatically gets loaded without needing to edit .vimrc or manually installing another plugin.

By default I don't think that it should change settings in .vimrc that are subjective (such as the colorscheme), it should just add the main plugin to Vim's runtime path (which will in turn add the others when its loaded and set defaults for other integration with other plugins). When you generate a .vimrc from scratch, and want to change some of Vim's defaults that are not OCaml related please use sensible.vim, anything more than that is probably subjective and may conflict with user's customization (such as the colorscheme).

FWIW these are my OCaml related settings in my .vimrc:

autocmd FileType ocaml set expandtab
autocmd FileType ocaml setlocal shiftwidth=2
autocmd FileType ocaml setlocal softtabstop=2
let g:syntastic_ocaml_checkers=['merlin']
let g:neocomplcache_force_omni_patterns.ocaml = '\h\w*\.\w*\|\h\w*#\w*'
let g:opamshare = substitute(system('opam config var share'),'\n$','','''')
execute "set rtp+=" . g:opamshare . "/merlin/vim"

The autocmd settings might be controversial, so its probably not a good idea to do them by default (unless ocp-indent requires expandtab to work, will have to check).

I'm not an emacs user, but emacs has a package manager now, and the preferred way seems to be to install stuff from ELPA/MELPA/marmalade repositories. Again it could be based on the same idea: one package that sets up emacs such that it loads all the stuff from the appropiate opam directories, sets up integration with other emacs packages and - since this is a real package manager - also depend on other packages that might be needed outside of opam (tuareg, etc.). See for example how Prelude does it. Care should also be taken if the user has a .emacs.d directory, but no .emacs file, I don't know what the effect is if you create a .emacs file in that case.

[AltGr]

Thanks for the input.

I agree that using modules fitting nicely in the editor's ecosystem would be best, and all your points above make sense. Let me explain my design choice though:

• Lazyness: well, not really, but we don't really have the ressources to put into writing and testing nice plugins for every editor (or 3, or 5 for each editor's various plugin managers). I'll be more than glad to use them if they're available from the community
• Simplicity: the system should be very easy to understand for anyone, and as such allow to customise the settings or disable very easily
• Target: this is mostly directed towards beginners and basic installations, as a starting point. I expect advanced users who like to tweak their editor won't want to use anything like this anyways.
• Ubiquity: there's currently emacs and vim, but because of the target, suppport for gedit, kate, sublime-text or others are as important. I wanted something low-level enough to work with any of them. All editors don't include a Turing-complete configuration language.
• OCaml: this was created at first to replace shell-scripts used in VM configurations, do this in a cleaner way and attempt to gather the scattered efforts in one place. Having advanced configuration scripts for specific editors is a very good thing that we should get to, but a bit beyond my current scope yet.

One thing that worries me a bit also, with using plugins downloaded from the editor's system, is that these need to be in sync with the corresponding packages in OPAM (ocp-indent, merlin, ocp-index are all an OCaml tool + editor bindings), and that sounds tedious to maintain.

All that said, it doesn't contradict your whole story. Indeed I have been installing the .el files from my packages under opamswitch/share/emacs/site-lisp for a while ; and as you mention, you may need a small modification of the base configuration file (.emacs, .vimrc), which user-setup provides, anyway. Since user-setup allows linking configuration files as well, you could well use it to locally install plugins.

The real limitation with the current approach is, indeed, that it's static. It's ok for the current target but may get annoying with multiple switches. The possible workarounds I see:

• use the editor's configuration language to do the dynamic loads ; this is kind of orthogonal to what user-setup provides, and what we are currently advising in the tools' documentations (run opam to get the load-path)
• have the editor run the configurator and read its configuration from its output. This is what ocp-edit-mode does for emacs ; it may not be possible for every editor, and supersedes editor config with a different configuration mechanism, which some users dislike.
• run it to update on 'opam switch' with some kind of hooks ; we may see if that is acceptable once we have the hooks in OPAM.

So the chosen approach seemed like the only consistent and generic way to provide what I wanted. It's probably not the best for any given editor, but a big improvement overall on what we had before.

On the other hand, if this is an occasion to gather efforts for OPAM to provide a consistent set of plugins for Emacs and Vim -- that'd be awesome.