Home
  
  

Vanilla Emacs or a Doom-stribution?

August 13, 2020

I started writing a small bit to share in the org-roam slack #random channel, but it kept growing and growing, so I broke it out into an note here, which seemed a little ironic but mostly fitting. I hope to maintain and add to this over time - feel free to share any thoughts!

The context: Emacs Distributions (like Doom and Spacemacs) vs Vanilla configurations. What is recommended for new users?

Note: I've spent very little time in Spacemacs, so can't speak to it vs Doom. I'd naively assume the pros/cons of Spacemacs are roughly the same as Doom's.

Vanilla Configs

Suggestion: Write your own, 'vanilla' emacs config from scratch, integrating and configuring packages one step at a time, learning how emacs' layers interact.

Vanilla Pros

  • A deeper understanding of Emacs, potentially a stronger foundation to build on, which may reduce the long-term maintenance cost.
  • The freedom and creativity of deciding how to integrate these features all on your own (i.e. keybindings, style, etc). (This can be done in the distribution as well, but I have a feeling some large portion of people stick with the default config's bindings and style.)

Vanilla Cons

  • Higher up-front cost for the same level of features.
  • If you want to stay up to date, higher maintenance cost.
  • If you don't want to update packages/emacs, general code-rot. No new features, no 'free' bug-fixes. Packages are bound to fall out of date in some ways as emacs itself gets updated, or when you need to reinstall the latest for whatever reason.

Jump straight into a distribution like Doom Emacs or Spacemacs

Suggestion: Follow the distribution's installation process, and (recommended) read whatever documentation they offer.

Distribution Pros:

  • Helpful packages have already been installed and configured, and things (presumably) work out of the box. This implies a working configuration for the languages you're already using, as well as for typical emacs packages (ivy/counsel, helm, magit, evil, etc.)
  • Useful patterns and miscellaneous emacs-headaches have solutions implemented by people who have experienced and thought about these problems (more than a new emacs user)
  • The community shares the on-going maintenance burden - shared bug fixes, anti-code-rot, and getting the most out of new features from emacs and package updates.
  • Doom's module system (opting in/out of sets of features fairly easily)
  • (If you're coming from a typical plugin-based vim config) Out of the box familiarity with vim-style keybindings and evil-mode-everywhere support

Distribution Cons:

  • Incurring bugs from community PRs and updates (presuming distribution instability, which can be mitigated but has indeed been the case before). Ideally there are no breaking changes, but it happens.
  • Shielding yourself from emacs vs doom vs package-x understanding when things go wrong.
  • More to learn all at once? This might be offset by documentation. Learning emacs implies learning a whole library of new terms.

Both

Pros

  • Help is not too hard to find.

Community support is pretty great in emacs, via reddit, stack overflow, and various chat apps.

I personally recommend and enjoy the Doom Discord. It's very active and there are always people getting help troubleshooting and adding new features. (Note that the main server is rule-gated!)

Cons

  • Over-investing in a potentially distracting meta-solution?

I always think of the time-savings graph on xkcd. By now, I love working this way, but what did I set out to do in the first place? Solve working-in-emacs?

Regardless of the solution, you'll have to work to maintain your config. That cost can be reduced, but can't really be zero. Though, I'd argue you maintain your workflow at some cost no matter what tool you're using.

Personal experience seeing others in Doom/Vanilla

I switched into Doom for three years ago before we hired a few new engineers (our team moved in size from 4 to 7). We thought it'd be a good idea to establish a team with a somewhat unified config and reduce onboarding/shared workflow differences. Doom's module system alone seemed like a great jumping off point. At this point (3 years later) about half of that team is still in doom, the other half maintain their own configs and use doom as a reference for misc emacs ui features/language configurations.

At that point doom was growing rapidly and one problem was getting burned by things breaking with the constant, bleeding-edge updates. Personally, I found these pushes inspiring and exhilarating - hlissner is a legend, and I love that develop branch! Where does he find the time? How is he this productive? But, things broke from time to time.

In the early stages of a distribution especially, you want people to be willing to 'own', fix, and open PRs for those issues when they happen. If you don't have vanilla emacs experience, it's a difficult ask. I do want to note that much of doom's tooling is oriented around maintaining doom - part of what keeps the development speed high is the way doom irons out edges around diagnosing and reproducing issues.

In a vanilla config, you start to appreciate owning your own config and learning the lower-level functions that are being wrapped by the distribution. But, having come from a vanilla setup, the opposite happens - you appreciate that someone's already started solving these problems in a reusable way (i.e. doom-core), and that there is a community that has spent time solving some of these bugs for you.

Using a vanilla setup gives you complete control - whether or not it's more work is a balance of how much 'surprise' work (i.e. bugs and breaking config changes) the distribution introduces. When that surprise happens, it is frustrating if you don't know whether the error you're seeing is due to the distribution or emacs itself. If you like debugging and can afford the time, this is a great learning opportunity!

There is an emotional advantage to running your own config - the solution might feel more possible if you know it's something you did, as opposed to something somewhere in this big code base.

I'd argue that you should try to feel the same personal ownership over the distribution you're running, as that's the mentality you and the community benefit the most from. Doom and Emacs make it quick to jump into the source of any module - for example, check out the helpful and doom-describe family of interactive functions.

This was opinionated!

This has been my experience, but I don't have much exposure to other opinions on this. Feel free to share any missing pros/cons either way, I'd love to know and incorporate them!

Backlinks

Russell Matney

Russell Matney

Writing, Stories, Software, Indie Games

 

© 2020