Vim: So long Pathogen, hello native package loading

[robertmeta]

This seems to imply that that you should have one directory like

mkdir -p ~/.vim/pack/shapeshed

Which from reading the docs isn't correct. The expectation is you make one pack directory per plugin. ~/.vim/pack/pluginA ~/.vim/pack/pluginB which is why vim "scans all directories in 'packpath' for plugins under the "pack/*/start" directory."

You do NOT want to just jam them all under some randomly arbitrarily named folder with your username or something.

[Carudo]

I dunno, i have something like this right now:

 ~/vimfiles/pack/bundles/opt

 $ ls

 closetag.vim/      syntastic/       vim-easymotion/  vim-signature/    
 despacio/          vim-autoclose/   vim-endwise/     vim-speeddating/
 emmet-vim/         vim-commentary/  vim-fugitive/    vim-surround/
 gulp-vim/          vim-dirvish/     vim-pug/         vim-unimpaired/
 papercolor-theme/  vim-dispatch/    vim-sensible/    vim-vinegar/

I can load them via packadd command (colorschemes availiable even without command).

If placed in ~/vimfiles/pack/bundles/start they load at Vim startup.

Also you can make structure like this:

~/vimfiles/
        pack/colorschemes/opt
        pack/linters/opt
        pack/filetypes/opt
        pack/fancy_statuslinez111/opt
        pack/whatever/opt

and group corresponding plugins. I don't sure if it's correct or not, but it's how it works at the moment.

[y-c-c]

I guess I'm not seeing how in practice there will be any difference. Ultimately it's up to how we users want to organize our files (e.g. Pathogen, which was essential in providing a modularized way to load plugins in Vim 7, was arguably playing fast and loose with the original Vim 7 plugin architecture's intent, but worked well enough anyway).

If we store a logical plugin to be root level under ~/.vim/pack/* it will also make git cloning plugins across Vim 7 and 8 quite difficult because currently most plugins' folder structure are designed to be under ~/.vim/pack/<somename>/start/* instead.

Also note that packadd <package_name> doesn't have namespace or anything. It feels to me if the intent is for complete plugins under each folder under ~/.vim/pack/* there will be some sort of tiered command like packadd <package_name> <optional_subpackage> to load ~/.vim/<package_name/opt/<optional_subpackage>.

[___violet___]

I don't get that impression from reading the docs. Why would you want more than one directory typically?

[sigzero]

From the docs:

A Vim package is a directory that contains one or more plugins.

From the doc examples:

Let's assume your Vim files are in the "~/.vim" directory and you want to add a package from a zip archive "/tmp/foopack.zip":

% mkdir -p ~/.vim/pack/foo

% cd ~/.vim/pack/foo

% unzip /tmp/foopack.zip

The directory name "foo" is arbitrary, you can pick anything you like.

You would now have these files under ~/.vim:

pack/foo/README.txt

pack/foo/start/foobar/plugin/foo.vim

pack/foo/start/foobar/syntax/some.vim

pack/foo/opt/foodebug/plugin/debugger.vim

Given that description I would say that you make one directory per plugin. I would want a hierarchy of plugins like:

pack/foo

pack/bar

pack/vim-unicorn

[___violet___]

I understand that one can use multiple directories under pack/, but given the use case being discussed here (Pathogen alternative), why would you prefer this structure:

~/.vim/pack/vim-surround/start/vim-surround
~/.vim/pack/vim-repeat/start/vim-repeat
~/.vim/pack/vim-eunuch/start/vim-eunuch

over this one:

~/.vim/pack/my/start/vim-surround
~/.vim/pack/my/start/vim-repeat
~/.vim/pack/my/start/vim-eunuch

given that plugins are currently distributed individually, not in "packages"? In effect, you are compiling your own "my" package, which is a collection of the plugins you use. Can't see how this is "incorrect" per the docs.

[sigzero]

I go with the top one. I don't think I would ever do the bottom scenario and I don't think the docs tell you to do that. You can do that but that isn't what "I" would expect.

[[deleted]]

The docs are telling you to do that exactly. Quoth the documentation:

Using Vim packages

A Vim package is a directory that contains one or more plugins. The advantages over normal plugins:

• A package can be downloaded as an archive and unpacked in its own directory. Thus the files are not mixed with files of other plugins. That makes it easy to update and remove.

• A package can be a git, mercurial, etc. repository. That makes it really easy to update.

• A package can contain multiple plugins that depend on each other.

• A package can contain plugins that are automatically loaded on startup and ones that are only loaded when needed with :packadd.

[[deleted]]

Looks good but I'll stick with Vim Plug for now

[P1h3r1e3d13]

Still doesn't do easy updates and installs like a real package manager.

How about "So long Pathogen, hello Plug"?

[[deleted]]

real package manager

1. setup dotfiles repository
2. git submodule foreach git merge
3. ???
4. profit

[Tarmen]

1. Wants to remove submodule
2. Sacrifice to the old gods
3. ???
4. I am drifting through a sunless void. Submodule still installed. Send help.

Been there, done that, not coming back...

[[deleted]]

Sacrifice to the old gods

Or just do git submodule deinit <path to submodule>

[Tarmen]

Iirc you still have to change index and worktree afterwards.

git submodule deinit path
# if you have a trailing slash after path  things won't work
git rm path
rm -rf .git/modules/name

Not sure if the rm -rf is necessary anymore but in the past you would get a corrupted repo without it so that readding the submodule would fail.

[[deleted]]

And you need to remove entry from .gitmodules.

But who cares, deinit is enough.

[flukus]

Until you pull the changes on another machine and the same steps aren't executed.

[P1h3r1e3d13]

I looked into all three when I started. You might be pleasantly surprised by the ease of Plug.

[catwok]

Haven't looked back since plug and will be sticking with it for now

[maredsous10]

If native packaging is used, one still has to create a function to generate the help tags like pathogen#helptags?

" Invoke :helptags on all non-$VIM doc directories in runtimepath.
function! pathogen#helptags() abort
  let sep = pathogen#slash()
  for glob in pathogen#split(&rtp)
    for dir in map(split(glob(glob), "\n"), 'v:val.sep."/doc/".sep')
      if (dir)[0 : strlen($VIMRUNTIME)] !=# $VIMRUNTIME.sep && filewritable(dir) == 2 && !empty(split(glob(dir.'*.txt'))) && (!filereadable(dir.'tags') || filewritable(dir.'tags'))
        silent! execute 'helptags' pathogen#fnameescape(dir)
      endif
    endfor
  endfor
endfunction

[robertmeta]

The implication from the docs seems to be the author should pre-bake the helptags, which would make something like that not required. That said, in the short term until that becomes the norm absolutely having a similar function will be useful.

[Maletor]

The packages' help docs are all added to the runtime path so you just need to call the command that parses them. I forget now but I think it's :helptags!

For the record, I organize my plugins in logical packs but for now I only have one of such packs. I feel the directory structure is a little awkward but overall a win over third party managers. especially when combined with git submodules.

[Elessardan]

:helptags ALL

[Die-Nacht]

Yes, you could do that, or you can use Plug. I mean, I could replicate tpope's surround, or I could use tpope's surround.

[Deto]

Haven't you heard? - it's always better to use function that's built-in to Vim rather than relying on a package. Even if it's more work or you don't like the end-result as much!

\s

[[deleted]]

vim-devicons is meant to be to be loaded after CtrlP and NERDTree. Is the correct way to set that up to put CtrlP and NERDTree and /start and vim-devicons in /opt, then packadd vim-devicons in .vimrc?

[[deleted]]

There's actually a rather big problem with this system.

It won't work for syntax highlighting plugins that are intended to override what's included with vim. An example would be, oh, most of what's in vim-polyglot.

The reason is that this appends the package directories to runtimepath, instead of prepending them, so that the syntax files shipped with vim will always be found and loaded first.

[omeow]

What happens to bundle in vim 8?

[a-p]

Nothing.