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
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.
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
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.