Moving from Vim to Emacs

I’ve been a staunch Vim user for a long time now, and recently switched over to Emacs. Time to fight the other side of the war!

I’ve got years worth of muscle memory tied up to Vim Key Bindings, so it’s unlikely that I’d have considered this change if it weren’t for evil-mode.

Before we start, an obligatory xkcd comic:

emacs_xkcd

Sections in this article:

Emacs Distribution vs Vanilla Emacs

I went for an Emacs distribution over vanilla Emacs because there were two things I didn’t want to have to configure for scratch:

I ended up picking Spacemacs, because the README resonated with what I was looking for, and it was pretty popular. I did feel that it was likely to be too bloated for my use case, but spacemacs-base (a minimal set of packages that you can build upon) seemed to solve that problem.

Spacemacs: The Good

A few features in Spacemacs that came as pleasant surprises:

1. Find/Replace Live Preview

Best explained with an asciicast:

Compared to this, find/replace in Vim feels like working with a blindfold on! (Yes, I do use :incsearch)

2. Case-sensitive substitution

Substitution in Spacemacs is case-sensitive by default, unlike in Vim where I had to use vim-abolish.

For a good explanation as to why this is useful, read vim-abolish’s README. A quick excerpt:

One time I had an application with a domain model called “facility” that needed to be renamed to “building”. So, a simple search and replace, right?

Oh, but the case variants!

vim-abolish combines all of these into one command.

3. Live Documentation

Learning key-bindings in Spacemacs is surprisingly easy, because it shows you suggestions as you start a key sequence.

which-key

I later learnt that this is powered by the which-key package.

Spacemacs: The Bad

Spacemacs shows a prompt on the first install that asks you whether you want to use spacemacs, the full-featured distribution, or spacemacs-base, a minimal set of packages that you can then build upon.

spacemacs-wizard

Since I wanted a minimalist setup that I could later configure as needed, I went with spacemacs-base.

When I did reach out for configuration options though, problems started cropping up.

While the Spacemacs config file is well-documented, a lot of the options in there only apply to spacemacs, and not spacemacs-base. Toggling config options felt something like this:

me: changes config value

Hmm, that didn’t work. Maybe I’m using the wrong value?

me: re-reads documentation

Doesn’t look like my mistake. Maybe a restart would help?

me: restarts Emacs

Still doesn’t work.

me: greps for config key in Spacemacs source code

me: finds the layer that uses it

me: tries to open layer documentation

spacemacs: layer not enabled

Oh, spacemacs-base 🤦

After a couple of encounters like this, it started to become clear that spacemacs-base was an afterthought, not a first-class citizen.1

I then switched to spacemacs instead of spacemacs-base. My mistake was apparent seconds later. After the reload, spacemacs installed ~140 packages (iirc). Opening a project was noticeably slower, and when I started editing files Spacemacs just kept freezing up randomly in the middle. Speak of bloat 🙄. I’m fine with not-so-fast startup times, but this was affecting basic operations like navigating through a file. (For context, I’m running a pretty lean setup: Arch Linux on an Macbook Air with 8 gigs of RAM)

I quickly course-corrected and switched back to spacemacs-base. Maybe the wrangling with disabled layers wasn’t so bad?

Spacemacs: The Ugly

Throughout my experience, the spacemacs documentation had always felt a bit rough on the edges. I was able to note down 3-4 mistakes (simple ones) in the first couple of hours. I didn’t make much of this at first, just assumed that it was because the project had a large amount of changes going in.

At the end of my first day with Spacemacs, I sat down to fix the documentation mistakes I had identified. As the contributing guide mentioned, I switched to develop. To my surprise, the fixes I intended to make were already present!

Assuming that these were recent fixes that hadn’t made it to master yet, I checked the date on those commits. They were created 2 years ago. I then checked the latest stable release for Spacemacs - turns out it was released more than a year ago. Something was wrong here. This isn’t what one would expect from a “community-driven” Emacs distribution.

I asked for help on Gitter, and was told to use develop instead of master. That didn’t sound right - The README didn’t mention anything about develop, and the online documentation was still wired to master.

I then asked about this on Reddit, and got this answer:

This is a persistent issue in the spacemacs community. I think only syl20bnr has commit access to master and so only he gets to decide what commits are worthy of being cherry picked into master. Master hasn’t had a version bumb in 2 years despite the v0.300 milestone being reached awhile ago. Here’s some github issues that raise your question: #12418, #11191

The deeper issue of maintainers and repository access was addressed two years ago. Unfortunately things haven’t improved much since then since than. While there are fewer open PRs, there are now over 2.3k open issues and that number only ever seems to grow. This continues to prompt questions of more active forks/better merging.

- reddit link

DOOM Emacs to the rescue

The fiasco with Spacemacs was enough to have me looking around for other alternatives. A quick search yielded a lot of praise for DOOM Emacs. I didn’t want to get rid of Spacemacs altogether just yet, so I used chemacs (an Emacs profile switcher) to install both side-by-side.

DOOM Emacs was far faster to boot, and had a more appealing & minimalist UI (IMHO). When I ran into installation troubles, doom doctor always had friendly error messages. I was also impressed by the quality of answers in their FAQ.

doom-emacs

I did have to customize DOOM Emacs a bit to get it running the way I wanted it to though. Spacemacs, in comparison, was more useable out-of-the-box.

News from the dark side

I’ve now gotten to a point where I’m comfortable using Emacs as my primary editor. I’m typing this article out in Emacs, with my web server process running in a terminal inside Emacs.

I haven’t opened Vim in 3 days. In fact, I’ve aliased it to launch Emacs instead.

My search history includes terms like “Todoist in Emacs”, “Web browser in Emacs” and “Email client in Emacs”.

…

I’m turning into one of those people, and I’m loving it.

  1. If this was designed better, I’d expect that in some form Spacemacs would be able to communicate the fact that a config option isn’t going to take effect because the requisite layers weren’t enabled. ↩