4 ms·

I'm genuinely curious why you'd really want native package loading in vim, except for purity's sake. If you're already using third party packages, is it much wo

by cjhveal 10y ago

I'm genuinely curious why you'd really want native package loading in vim, except for purity's sake. If you're already using third party packages, is it much worse to just add a package manager? I've been using junegunn's excellent `vim-plug`[0] for a while now and it's worked really well. Some of the benefits I can see over the native approach here: - Declarative configuration suitable for version control. - Parallel installation/update. - Run scripts or makefile on install/update. - On-demand loading based on open filetypes. [0]: https://github.com/junegunn/vim-plug https://github.com/junegunn/vim-plug

egwynn 10y ago
Part of the issue is that vim’s ages-old plugin model uses a really unusual and frustrating architecture. I think the purpose here is to make the baseline package system cleaner, so that more advanced package management systems don’t need to reinvent the wheel so much.
joemi 10y ago
Personally, none of the bullet points you mentioned matter to me at all, so I'm glad about the improved native package loading. Plus, I've always found it weird to need a package in order to load other packages (in a remotely sane way). As your comment implies, vim's improved package handling is still pretty simplistic compared to some existing plugin managers, so there's really no reason _not_ to want the functionality in vim. It's not like it was a huge addition to the code that's now slowing down your system, or messing up existing plugin managers. Similarly, it's not going to cause fuller-featured plugin managers to cease further development.
- eridius 10y ago
  On-demand loading is useful, because it speeds up launch time. You could have hundreds of packages installed, but if they're all on-demand, launch can still be blazing fast.
  - joemi 10y ago
    I think you're missing my point. I wasn't arguing against more feature-filled package managers. I was answering cjhveal's genuine curiosity about why you'd really want native package loading in vim.
smonff 10y ago
Because Emacs made it.

by cjhveal 10y ago

egwynn 10y ago

Part of the issue is that vim’s ages-old plugin model uses a really unusual and frustrating architecture. I think the purpose here is to make the baseline package system cleaner, so that more advanced package management systems don’t need to reinvent the wheel so much.

joemi 10y ago

Personally, none of the bullet points you mentioned matter to me at all, so I'm glad about the improved native package loading. Plus, I've always found it weird to need a package in order to load other packages (in a remotely sane way). As your comment implies, vim's improved package handling is still pretty simplistic compared to some existing plugin managers, so there's really no reason _not_ to want the functionality in vim. It's not like it was a huge addition to the code that's now slowing down your system, or messing up existing plugin managers. Similarly, it's not going to cause fuller-featured plugin managers to cease further development.

eridius 10y ago
On-demand loading is useful, because it speeds up launch time. You could have hundreds of packages installed, but if they're all on-demand, launch can still be blazing fast.
- joemi 10y ago
  I think you're missing my point. I wasn't arguing against more feature-filled package managers. I was answering cjhveal's genuine curiosity about why you'd really want native package loading in vim.

smonff 10y ago

Because Emacs made it.