Vanilla Emacs or a Doom-stribution?

Created: Aug 14, 2020Published: Mar 28, 2023Last modified: Apr 05, 2023
Word count: 1151Backlinks: 3

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

Emacs is a text-editor that is quite old, but has been worked on continuously since then.

Emacs is special because it is very dynamic. It is implemented in lisp, which allows interactive development via the REPL, giving you tons of power and control. It is a double-edged sword, in that you must take care to keep your systems running smoothly. Tools are everything, so keep your knives sharp.

Emacs can be very difficult to learn, especially in a vacuum. I hope to document the things that have been useful to me.

Some emacs notes:

Emacs has a pretty high onboarding cost. Getting started can be tough, depending on your expectations and whether or not you are close with someone else already familiar. Getting help and seeing emacs used well in person makes a huge difference in learning and onboarding time. If you can, I recommend getting exposure to how it can be done!

As with most highly useful and old tech, there is already a community of people and resources that provide immense value. A big part of getting started is taking the time to collect and curate your resources, and setting yourself up for the long haul. To me, that means finding useful blogs, email newsletters, subreddits, slacks/discords/ircs that you can lurk on. This lets you start tracking the progress and current conversations in the community over time, and you'll start to learn that there is a wide-spectrum to each community. Just like the javascript ecosystem, you really just want to start running with the pack, and soon enough you'll be moving on to learning the next thing with everyone else.

Here, I'm collecting useful emacs docs and resources.

See also:

Doom Emacs is an emacs distribution that initially catered to ex-vimmers, and has since grown to be an excellent way to run emacs.

See also: