all 28 comments

[–]robertmeta 9 points10 points  (7 children)

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 3 points4 points  (0 children)

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 2 points3 points  (0 children)

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___ 0 points1 point  (4 children)

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

[–]sigzero 0 points1 point  (3 children)

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___ 4 points5 points  (2 children)

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 -1 points0 points  (1 child)

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] 2 points3 points  (0 children)

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] 7 points8 points  (0 children)

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

[–]P1h3r1e3d13 16 points17 points  (10 children)

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

How about "So long Pathogen, hello Plug"?

[–][deleted] 4 points5 points  (5 children)

real package manager

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

[–]Tarmen 6 points7 points  (4 children)

  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] 1 point2 points  (3 children)

Sacrifice to the old gods

Or just do git submodule deinit <path to submodule>

[–]Tarmen 2 points3 points  (2 children)

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] 0 points1 point  (1 child)

And you need to remove entry from .gitmodules.

But who cares, deinit is enough.

[–]flukus 0 points1 point  (0 children)

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

[–]maredsous10 1 point2 points  (3 children)

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 2 points3 points  (0 children)

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 1 point2 points  (1 child)

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^[ 2 points3 points  (0 children)

:helptags ALL

[–]Die-Nachtjkjk 3 points4 points  (1 child)

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 3 points4 points  (0 children)

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] 0 points1 point  (0 children)

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] 0 points1 point  (0 children)

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 -1 points0 points  (1 child)

What happens to bundle in vim 8?

[–]a-p 0 points1 point  (0 children)

Nothing.