My Emacs Config Journey

July 6, 2020

At the end of the day, your emacs config is your own.

Whether your using an emacs 'distro' like Doom or Spacemacs, or writing your own config from scratch, all the code and state built up when you start emacs is something you should own and learn how to debug.

I have been through 3 or 4 rewrites of my emacs configuration, and have ended up on Doom Emacs. I've seen hit or miss experiences with Doom from fellow coders, and so far, the ones who have left Doom preferred to build their own emacs configs from scratch. I definitely recommend that! The experience will teach you all that Doom has protected you from, or what pain it caused you. In the end, whichever way you go, you'll be able to appreciate either that Doom has good coverage, or that if something goes wrong, it's your fault.

Rough outline of my emacs config journey - hopefully this gets more structured attention over time:

Note that I came from a few years of building up a vim/neovim config.

An initial vanilla emacs config or two

The pains of learning some elisp and configuring via use-package.

My killer-feature at first (vs. vim) was M-x + Helm (fuzzy-finding for every interactive command! Discoverability!).

Discovered org mode, become obsessed

Why do we even have code files? Literate programming!

I moved my config completely into a single org-file, and org-babel-ed/org-tangle-ed all the things.

A vanilla basic emacs config, part 2

Ultimately the literate config felt like more prose than code, and I left it when I felt it was encouraging me to write more about my config more than actually fix the issues in it.

Also, order-mattering between org-babel/tangle blocks became annoying. I'm sure it's solvable, but at this point that felt like I was maintaining the wrong thing (my literate config tooling, rather than the config's features itself).

Doom Emacs

I've been here since late 2017, and have not wanted to leave.

It was chosen before adding more engineers to the team at work. The hope was to standardize, so that we could grow together across the team. It worked, sort of.

For developers coming from a general vim+plugins+tmux experience, Doom is well within reach - most things will just work, and the learning is about getting all the new emacs keywords and plugins integrated into memory. Ex: magit, helm, ivy/counsel, etc.

I've not really debated leaving Doom. Instead, I actually enjoy learning more and more of Doom whenever things go wrong. The community is strong - I enjoy seeing PRs that upgrade language configs to use the latest tools. It feels like my config is being maintained for free, cutting off problems that come from bad package updates or other newly introduced emacs bugs.

There are times where things go wrong, and you need to dig or search for the solution instructions. Mostly they are solved within a day by someone in the community, which is about how long it'd take me to figure it out anyway.


Russell Matney

Russell Matney

Writing, Stories, Software, Indie Games


© 2020