On Sat, Jun 18, 2016 at 11:55:17PM -0400, James McCoy wrote: > On Jun 18, 2016 6:03 PM, "Josh Triplett" <j...@joshtriplett.org> wrote: > > [Note: in addition to changing vim-addon-manager, this would ideally go > > along with some minor updates to the vim packaging policy in the vim > > package; I'd be happy to supply a patch for that.] > > N.B., vam already has some support for using a directory to contain a > plugin, like pathogen does. This wasn't officially announced because of a > bootstrapping issue which is now solved with Vim's packages. > > I'm currently working on getting that merged in NeoVim so we can have > consistent handling. > > > This format has the advantage that the user can add a single directory > > (or symlink) for a package, keeping all that package's files together. > > Agreed. It solves a number of issues which have been the main things > holding me back from updating the vim-scripts package.
Awesome. > > I would suggest installing packages under /usr/share/vim/packages, and > > replacing the "files" key in the registry yaml files with "package: > > pkgname", where pkgname matches the top-level directory in > > /usr/share/vim/packages. When installing a package, vim-addon-manager > > should just make a single symlink from ~/.vim/pack/$pkgname to > > /usr/share/vim/packages/$pkgname. > > Good suggestions. We currently use ~/.vim/bundle iirc, but since I don't > think it's really used anywhere, I'd be fine changing it. Some of the "automatically download and run code from github" plugin systems use "bundle". vim's built-in package handling uses "pack". > My remaining quandary is how to properly handle disabling a systemwide > plugin while not interfering with a user's plugin of the same name (e.g., > installing a newer version locally when the sysadmin also has it enabled). I don't think that issue works any better with the current non-package-based approach, and I don't think this change has to solve all problems. The "disable" mechanism already exists to handle disabling a system-wide enabled package. If a user wants to override a system-wide enabled package, they could potentially override runtimepath or packpath to leave out the system directories. (Or complain at the sysadmin for enabling a vim package system-wide on a multi-user system.) - Josh Triplett