I was a Vim user for 15 years until the shine of newer editors caught my eye. Since 2016, I’ve been exploring the wilderness: Sublime, Atom, Spacemacs, PyCharm, VSCode, and Spacevim.

In 2016, I started experimenting in response to my new co-workers. I spent the previous nine years working in an environment where many engineers used either Emacs or Vim. Upon leaving that environment, I found myself in a strange new world. Many of my new teammates were using Sublime or Atom. I tried each of them in turn, thinking maybe these engineers knew something I didn’t.

Sublime and Atom quickly disappointed. Neither had great Vim support. Sublime was at least usable, but Atom was so slow that it was laughable. Continuing to use either of these would have been like asking a farmer to plow a field with a tractor having square wheels.

Over the years I had made several attempts to use Emacs. Those attempts, however, never lasted long. The key bindings stretched my fingers in ways I never knew possible. I was also worried about the long-term effects of Emacs usage, seeing my older self walking around with arthritic fingers shriveled from years of Emacs abuse. But then a co-worker turned me on to Spacemacs. It claimed to be the best of both worlds: “The best editor is neither Emacs nor Vim, it’s Emacs and Vim!” according to its website. Based on Evil, the “extensible vi layer for Emacs,” Spacemacs also fell short. It introduced a whole new layer of keybindings under the pillars of “Mnemonic, Discoverable, Consistent.” And Spacemacs did deliver on those pillars, but it certainly didn’t feel like Vim.

Next up was JetBrains' PyCharm. I was writing a lot of Python at the time, so this seemed like a natural choice. JetBrains offers IdeaVim, a “vim emulation plugin” for its Intellij-based editors. IdeaVim worked well enough, but it felt clunky. Vim support worked fine as long as I was moving around a single file, but interacting with other features didn’t have an equivalent binding. Thus, I ended up with a mashup: using Vim bindings for navigating and editing a single file; learning and using PyCharm’s own keybindings for other features like splitting windows. I attempted to customize Pycharm’s keybindings, but I quickly gave up. Most attempted changes resulted in Pycharm yelling at me about the key being already used by some other feature.

Then VSCode arrived on the scene. Like everyone else, I was impressed. Here was an opensource product from Microsoft, of all companies! And it was actually a surprisingly good product. An electron app, it felt like a grownup version of Atom. It too had support for Vim keybindings via a plugin, VSCodeVim. Though I liked VSCode better than PyCharm, it ultimately suffered the same problems as IdeaVim. It felt clunky, because the Vim bindings were a faithful emulation as long as I was working on a single file, but even then some of the Vim bindings only worked if I configured VSCode to use Neovim instead of Vim.

In the last month, I’ve returned to Vim itself. It started with Spacevim, which, as its name suggests, was inspired by Spacemacs. The main benefit of Spacevim is its configuration. Instead of using the traditional .vimrc and vimscript, Spacevim uses a Toml config file, which makes the config more of a declaration; under the hood, Spacevim takes care of managing plugins and other features. While the configuration was simple, it didn’t seem to provide much of advantage. In many ways the simpler configuration was deceiving. In trying to make the original product easier to configure, they actually introduced a whole new layer between the user and the configuration, and that new layer isn’t any simpler than the original layer. My current .vimrc is only 91 lines. My Spacevim config was 79. Under the hood, however, the Spacevim config ends up influencing five other configuration files:

• functions.vim
• general.vim
• init.vim
• main.vim
• neovim.vim

The above files have a total of 351 lines, not counting init.toml. So, if anything didn’t work as expected, I’d likely have to figure out which of these five files were involved, then dive in to it to figure out what it was doing.

I used Spacevim for a couple weeks. It felt comfortable enough, and I was just as productive with it as I was with pure Vim. Ultimately, though, it reminded of Spacemacs. In trying to make the original product easier to configure, they actually introduced a whole new layer between the user and the configuration, and I’m not sure that new layer is any simpler than the original its trying to abstract.

So, in the last week, I’ve returned home to Vim proper. I’ve been pleasantly surprised. There are new features in Vim8, such as the new built-in package management system that makes plugin managers like Vundle or Pathogen obsolete. Now, it’s simply a matter of cloning a plugin’s repo into a specific directory, and I was off and running. At present, I’m using only eight plugins:

• coc
• ctrlp
• fugitive
• nerdtree
• syntastic
• vim-airline
• vim-code-dark
• vim-go

Each of these plugins I’ve configured to my own personal tastes. Several of them I was using in Spacevim, but for some reason the full configuration options weren’t exposed in Spacevim (or I couldn’t find them in the documentation).

My intent here is not to bash any of these other editors, nor to disparage their users. Like any piece of technology, including Vim, they all have their pros and cons. If a user feels comfortable and productive using any one (or multiple) of these editors, then great! I’m not advocating for a single editor to rule them all.

Instead, the experiences I describe above reminded me of Heinz Kabutz’s essay from 97 Things Every Programmer Should Know. Titled “Know Your IDE,” the final sentence summarizes nicely what I’m trying to say here:

We expect a plumber coming to our house to be able to use his blowtorch. Let’s spend a bit of time to study how to become more effective with our IDE.