The vi editor was initially released back in 1976, and quickly became established as the default “visual” editor on Unix systems. In 1991, Bram Moolenaar released “vi improved”, or simply vim.
One of the improvement vim offered over the original vi was extensive customisation, including the use of plugins. In the early days, users had to install and manage vim plugins by hand. That was more messy than difficult, but it lead to development of vim “plugin managers”.
Two of the more popular plugin managers were Vundle and Pathogen, and they did a great job. The irony was that Vundle and Pathogen were themselves vim plugins, but once one of them was installed and configured, adding and removing other plugins was much easier.
vim package handling
Bram continues to develop vim, and constantly tries to improve it. With the release of vim 8, released in September 2016, vim can now handle plugins itself. There’s a useful article about how vim manages plugins and how to configure it here.
That works, but…it isn’t easy. In fact, it took me some considerable time to configure vim to use native package handling, and I was struggling to find a good reason to migrate from Pathogen, which I’ve used for years.
Advantages of vim's native package handling
- If you have a need to load/unload vim plugins on demand – perhaps you develop vim plugins – there is a useful command set within vim 8 do to this.
- It’s native: no plugin to manage plugins
Disadvantages of vim’s native package handling
- It’s not particularly user friendly
- Help tags are not automatically generated
- All management of the plugins remains that of the user
This tip
Perhaps somewhat oddly, this tip is to not use vim‘s native package handling unless you have unusual requirements.
What are your thoughts on vim‘s package handling?
Let us know in the comments below.