Introduction

When I started my Vim adventure a couple of years ago, I took one “sensible configuration”. It comprised of the settings that combined provided a pretty neat environment for beginners. It also included several plugins that extended the functionality of the editor. Over the years, I tweaked the configuration to my needs. I learned more about Vim’s features, changed the settings to my own needs. The adjustments included adding and removing plugins as well.

When I trace back the history of changes to my .vimrc file, one trend is clearly visible. The number of plugins included in the configuration was decreasing. Finally, a couple days ago I watched this talk by Max Cantor. I decided to revise the remaining plugins and assess if they are really necessary for my workflow or can be replaced by the editor features. And the answer was simple: yes, I can safely get rid of all the remaining plugins and happily edit my files with just plain Vim. In this article, I will present what plugins were the last I used and how I managed to replace their functionalities.

The last plugins

Vundle

Vundle is a plugin manager for Vim. Its sole purpose is to install and maintain the plugins. The decision about removing this one was straightforward. Since I decided to get rid of all plugins entirely, I would not need a plugin manager anymore.

Fugitive

Of all the plugins, Fugitive was certainly the most useful one. It provides integration with Git inside the editor. Basically, it is a thin wrapper over the git executable. The output of the version control commands is nicely integrated with the Vim buffers. Also, this plugin adds some keybindings and functions that speed up the interactions with git.

I used this plugin daily. Committing changes and pushing to the remote repository was extremely easy with provided functions. However, there were certain operations I was more comfortable performing directly in the shell instead of through the editor. For instance, I found it more convenient to fetch the changes from the remote and do a rebase from within the command line. As a result, the verdict for Fugitive is to remove it. After a couple of days, I must admit that my performance was not harmed. On the other hand, I was forced to get more familiar with the commands that were wrapped by the plugin. One such example was git restore. This powerful function was available as a single keystroke. As a result, I never had an urge to check its documentation and learn more about the details.

Gitgutter

Gitgutter displays git diff on the left side of the text. The changes are shown in real-time. To be frank, this plugin came with the very first configuration I used for my Vim setup and stayed with me till now. Honestly, I did not pay too much attention to what was displayed in the column on the left. When I code or write a text, I don’t pay too much attention to the current diff. I focus on the text in front of me. The diff becomes important when I start to stage the current changes. However, tools like git diff or its frontend git difftool do a much better job showing me what changed. In fact, I should have removed this plugin a long time ago, as it actually was never of use to me.

Unimpaired

Unimpaired provides a set of useful mappings to perform various common tasks that form pairs. Examples of such actions are navigation or toggling options. The list is pretty impressive. However, I used only two sets of mappings daily: navigation in the quickfix list (]q and [q) and jumping between open buffers (]b and [b). I decided that those two features are not enough to keep this plugin my configuration.

Removal of Unimpaired had an unexpected effect of… making my navigation more effective. When the shortcuts I used were gone, I was forced to read a little bit more about how to use these two specific features. I found out, that there are much more efficient ways to perform the tasks. For the quickfix list, I found the :cl command that shows the actual content of the list. It turned out to be much faster to find the element I needed in the list than jumping a single element at a time. As for buffer navigation, I started using the :b command. When this is combined with wildmenu, it allows me to perform a fuzzy search and jump to the desired buffer immediately.

Surround and Repeat

The two plugins are connected. Surround allows to edit the surrounding parentheses or quotation marks around chunks of text. Repeat plugin allows the composite commands to be repeated with ..

The reason to remove this plugin was similar to the Unimpaired plugin. Recently, I did not use it much. I also found the default keybindings provided by the plugin a little bit too complicated, especially combined with some more sophisticated movements. In some cases, I found it easier to navigate to the beginning of the text to be wrapped, insert opening parentheses, navigate to the end of the chunk, and close the parentheses manually. When I removed the Surround plugin, the Repeat plugin became obsolete as well.

Lightline

The Lightline plugin offers a fancy, configurable status line. However, when I got acquainted with the possibilities of a built-in status line, I found this plugin redundant in my use case.

For some time now, I’ve been leaning towards the tools that do what I want them to do and then get away and don’t clutter my screen with information I no longer need. As a result, I even removed the current path and git branch from my ZSH prompt. If I need to know where I’m operating at the moment, git status and pwd get me covered. Consequently, the only feature that Lightline gave me, was built-in support for several color schemes. It was not enough to keep this plugin in my configuration. To get rid of Lightline, I utilized the Vim status line to display absolutely required fields. The vanilla status line has also one advantage over Lightline. The configuration is much more concise. Here you have my last configuration of Lightline:

"----- LIGHTLINE SETTINGS----
let g:lightline = {
    \ 'mode_map': {
        \ 'n' : 'N',
        \ 'i' : 'I',
        \ 'R' : 'R',
        \ 'v' : 'V',
        \ 'V' : 'VL',
        \ "\<C-v>": 'VB',
        \ 'c' : 'C',
        \ 's' : 'S',
        \ 'S' : 'SL',
        \ "\<C-s>": 'SB',
        \ 't': 'T',
    \ },
    \ 'colorscheme': 'PaperColor',
    \ 'active': {
    \   'left': [ [ 'mode', 'paste' ],
    \             [ 'gitbranch' ],
    \             [ 'relativepath', 'modified' ]],
    \   'right': [ [ 'syntastic', 'lineinfo' ],
    \              [ 'percent' ]]
    \ },
    \ 'inactive': {
    \   'left': [ [ 'gitbranch' ], [ 'relativepath', 'modified' ] ]
    \ },
    \ 'component_function': {
    \   'gitbranch': 'FugitiveHead'
    \ },
    \ }

And here is my current status line configuration with plain Vim:

" statusline
set statusline=\ 
set statusline+=%f
set statusline+=\ %m%r%h%w
set statusline+=%=
set statusline+=%y
set statusline+=\ %l:%c
set statusline+=\ %p%%\ 

The Lightline configuration was indeed much more human-readable, but with some help of a reference manual one can easily set up her own status line. Also, note that I have some entries that I don’t need to be displayed all the time.

PaperColor theme

PaperColor is a color scheme I started using some time ago. It replaced the good old Solarized Light theme. I find PaperColor a bit easier to read on the smaller screen of my 13" ThinkPad.

In the case of the PaperColor plugin, I did not actually get rid of it, as restoring the theme with the Vim settings would end up copying the plugin code. Instead, I moved away from managing this plugin with Vundle. I simply added the PaperColor repository as a submodule to my dotfiles repository and created symbolic links in the ~/.vim/colors directory. As a result, I didn’t need to keep Vundle around for just a single plugin.

Colorschemes

The Colorschemes plugin was a part of the very first version of “sensible” configuration for new Vim users. This plugin includes a wide variety of color schemes that are ready to use. This could be great for the new Vim users as they can easily experiment with changing colors of their editor to find the most suitable one. However, from the very beginning, I used the single theme only. As a result, I should have removed the Colorschemes plugin long before. I didn’t. Currently, I can’t exactly say why. It just followed me with my Vim journey for all these years.

Caw

Caw provides comment management for several different languages. It adds bindings that allow the developer to insert or remove comment marks for a given line or lines. It can detect the language automatically.

The reason for ditching this plugin was simple. One day I realized I don’t use it very often. Even if I needed to comment out the big section, I found myself falling back to the visual block mode and inserting the required marks in front of each line. As a result, there was no need for me to drag the whole plugin code with my configuration.

Lexima

I have very mixed feelings regarding the Lexima plugin. Its purpose is to automatically add closing parentheses. This is certainly useful when writing large pieces of new code. However, this feature was getting annoying for writing prose or editing existing code. I found myself deleting the unnecessary closing characters more often than taking advantage of autoclosing. The decision was simple. Lexima had to go.

fzf.vim

fzf.vim is a simple wrapper around the fzf utility. The tool provides a fuzzy search for the command line. My main use of this plugin was to navigate between files in the current directory and all its subdirectories. The biggest advantage of this plugin is its speed. The list of files appears immediately on the screen. Also, the search was performed extermely fast.

I was very surprised to find out, that with a proper configuration Vim provides almost similar functionality. The wildmenu and :find command followed by the TAB key allows the user to browse the list of files that match the given string. One thing to note is the fact, that fzf performs much faster inside hierarchies that contain a lot of files. However, I find the :find command much more convenient in situations when I know the name of the desired file exactly. With fzf.vim my screen would go cluttered with a listing of all files, increasing the amount of noise in the window. Since my mission was to remove as many plugins as possible, I decided to let fzf.vim go. Built-in file search is just enough and provides a much less intrusive experience.

Polyglot

Polyglot provides a language pack for syntax highlighting. It extends the set of rules that are already bundled in Vim. The list of supported languages is pretty impressive. However, default Vim installation has a wide variety of covered syntaxes as well. Furthermore, the default Vim language pack covers all the languages I work daily. Thus, the Polyglot plugin was rendered obsolete by not bringing any additional value to me.

Vimwiki

Vimwiki provides a wiki to maintain a personal knowledge base. When I installed this plugin, I intended to gather useful notes in the wiki form. Then the reality came, and I ended up having only notes from one online course I attended at that time. In other words, I used this plugin once, and then I was just taking up the space on my machine.

Conclusion

I must state one thing clearly. My point is not that the plugins are bad and you should not use them. Quite the opposite: If you find a plugin solving a problem for you, go for it. These are just the tools that should let us do the job done. For me and my use cases, the plugins turned out to be unnecessary. As a result, my Vim configuration became leaner and cleaner.

I was also forced to dig deeper into Vim’s documentation. Consequently, my understanding of this editor increased. In fact, this program contains a lot of features that make text editing more pleasant and efficient.

One thing probably popped to your mind: how uninstallation of the plugins did decrease the startup time? To be frank, not much. I bet that the editor starts up a bit fast. However, the difference is not visible. Both, with and without plugins, my Vim started almost immediately.