<p dir="ltr">On Jun 18, 2016 6:03 PM, "Josh Triplett" <<a href="mailto:josh@joshtriplett.org">josh@joshtriplett.org</a>> wrote:<br>
> [Note: in addition to changing vim-addon-manager, this would ideally go<br>
> along with some minor updates to the vim packaging policy in the vim<br>
> package; I'd be happy to supply a patch for that.]</p>
<p dir="ltr">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.</p>
<p dir="ltr">I'm currently working on getting that merged in NeoVim so we can have consistent handling.</p>
<p dir="ltr">> This format has the advantage that the user can add a single directory<br>
> (or symlink) for a package, keeping all that package's files together.</p>
<p dir="ltr">Agreed. It solves a number of issues which have been the main things holding me back from updating the vim-scripts package.</p>
<p dir="ltr">> I would suggest installing packages under /usr/share/vim/packages, and<br>
> replacing the "files" key in the registry yaml files with "package:<br>
> pkgname", where pkgname matches the top-level directory in<br>
> /usr/share/vim/packages.  When installing a package, vim-addon-manager<br>
> should just make a single symlink from ~/.vim/pack/$pkgname to<br>
> /usr/share/vim/packages/$pkgname.</p>
<p dir="ltr">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.</p>
<p dir="ltr">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).</p>
<p dir="ltr">Cheers,<br>
James</p>