The Dao of Emacs, and my mixed feelings on Doom Emacs

One of the most powerful aspects of Emacs is that it can truly become anything you want it to be. This is definitely a good thing, as I've spent a lot of time explaining above: malleable tools give you freedom, autonomy, control over your own computing life. You can shape them to best help your workflow, your thought process, your preferences, your needs (even physical ones). They grow with you, around you, rewarding you for the time you spend with them. They have better longevity, because they can change and adapt with the times, integrating new features and strategies as they arise in the surrounding world, never truly becoming obsolete, meaning that the time you invest into them isn't wasted.

There is such a thing as "too much of a good thing," though. Because Emacs can become anything you want it to be, there's this temptation on the part of people first coming to the editor to immediately terraform it. To rebind all the keybindings, to replace its core editing concepts and philosophy with something else, to replace its package management and configuration system, substitute built in user interface concepts for different ones. To reiterate, I'm glad that you can do this. The fact that this is possible is a deeply positive thing. I think software power tools and computing environments should be things that can be shaped to their individual users. The question is when you should use this power.

There is a cost to customization, even with Emacs. With every extra package, with every custom function, every involved piece of extra logic, you add complexity that will weigh you down: customizations can introduce conflicts with core Emacs or with each other, inconsistencies in your interface if there are certain lacunae where your modifications don't apply, or edge cases that you didn't account for. External dependencies might break with future updates, or not translate properly across machines. With every replaced keybinding, changed UI paradigm, new command, and personal modification, you venture farther and farther from the vast swath of high-quality Emacs documentation or the Emacs community being able to help you, or even reproduce any issues you might be facing. Not to mention that if you're not extremely careful and OCD about what you load when and how, and aren't aware of how to optimize Emacs, all these customizations can seriously effect your editor's performance. Emacs can be pretty god damn fast, but you can also make it very slow very easily. All of this inevitably leads to the infamous state of .emacs bankruptcy.

Furthermore, if you immediately change it to suit your pre-existing preferences, expectations, and knowledge, you also miss out on the powerful features that already exist inside Emacs that might be even better than what you're used to or even expecting. That doesn't have any inherently negative consequences per se, unlike the added complexity, but it's a missed opportunity. It also disconnects you from the wider world of powerful and interesting packages that are designed to integrate with a more vanilla Emacs, of which there is a far wider and more well-developed selection than for any complete Emacs overhaul package, since more Emacs users use (and have used, over time) close to vanilla Emacs over very highly modified Emacs setups. Packages like objed, expand-region, puni, smartparens, paredit, and most of the applications written for Emacs. Of course you can rope those packages in, but it usually requires extensive configuration (see evil-collection) and will never be quite as functional.

The solution for this is not to pursue minimalism in your Emacs config to the detriment of your workflow, desires, quality of life, or desired functionality, of course – that would defeat the entire purpose of what Emacs is. It would be holding minimalism as a fixed idea in contradiction to your own desires, interests, and ends.

Instead, understand customizing Emacs through the concept of wu wei. Wu wei is a concept from Daoism which means something like "effortless action." It is the ideal of being fully in tune with the ways of the world around you (its Dao), knowing it intimately, being receptive to it, bending with the currents as much as possible instead of fighting them at every turn, so that when it comes time to act you understand what is around you and can swim with those currents, using their momentum to move you in the direction you want to go, and even when it comes time to fight the current, you can do it efficiently, effortlessly, because you've conserved your energy in all other respects and you understand the flows and eddies. Understand the Dao of Emacs before you try to change it. Conserve your energy by changing it as little as possible, so that when you really do need to change it, you have as little weighing you down as possible, and you can do it effectively.

Those new to Emacs, who want to truly understand it, should spend time coming to be familiar with its concepts, its built in functionality and packages, its native keybindings. Emacs is the natural world of your new computing environment – come to understand it before you change it. And when you do change it (and you will) ask yourself these questions:

1. Can I change my muscle memory, workflow, or needs, in a small way to achieve what I want with what I already have?
2. Can I customize Emacs in a small way – setting some customization variables, adding a small hook, adding some advice, etc – to achieve what I want?
3. Can I use a small, stable package with limited functionality, that builds on and expands Emacs's core packages, functionality, and ideas, to achieve what I want?
4. Is there a package that integrates well with existing Emacs functionality, such that nothing else in my configuration will need to know it's there, even though it's a big change, to work? (such as Vertico, marginalia, or orderless, over Helm)?

The point of the malleability of Emacs is that sometimes you really do need that malleability, and so it should be there for you when you need it – not that everything should be completely changed all the time. Do the smallest intervention, the littlest thing, that will achieve what you desire.

Which brings me to Doom Emacs.

Doom Emacs is the antithesis of this philosophy. As it says in its GitHub description, it is "an Emacs configuration for the stubborn martian vimmer" – in other words, it is an Emacs configuration for those who don't really want to use Emacs. And this description only holds up more the more you look at it, because Doom Emacs is an ecosystem unto itself, almost totally separate from the surrounding Emacs ecosystem:

1. Every keybinding (and even mnemonic) has been completely overridden and replaced, meaning that most packages that haven't explicitly been wrapped in layers for Doom Emacs cannot easily be used, existing editing packages and modes can't be used, existing Emacs documentation is almost useless, and other Emacs users can't help you.
2. Its package system and configuration framework are completely different, meaning you can't use the default installation instructions for most Emacs packages (even the compatible ones) or share code with non-Doom users' configurations.
3. Its entire editing system and set of concepts has been supplanted (with evil mode).
4. It doesn't even want you to install packages or do customizations yourself most of the time (partly because of 1 and 2), keeping you abstract from even its own alternate package management and configuration system through its module/layer system, a declarative customization system where you comment or uncomment lines representing various uses of Emacs (mail, RSS, different languages, terminal emulator, etc) and then Doom Emacs chooses which packages(s) to use for things, and how to configure them and map their keybindings for you, without you ever having to even interact with the concept of configuration or managing packages or see a single line of actual Lisp.

There are clear benefits to this approach, of course:

1. Most people interested in Emacs will be coming from Vim or NeoVim, and will want to bring all their editing knowledge and muscle memory with them – as well as probably, half-correctly, believing in the superiority of Vim's editing grammar, and correctly believing in the ergonomic superiority of modal editing – so providing them with a Vim implementation of editing right out of the gate is important, and of course then the rest of Emacs's keybindings need to be terraformed to conform to those expectations, leading to the extensive need for leader key keybindings and so on.
2. Likewise, while great, `use-package` (and its underlying system, `package.el`) aren't the most reproducible, and they're also single-threaded and a bit slow.
3. Furthermore, those who aren't so sure about Emacs, who aren't fully committed, but just want to try it out to see what it can do, and want something that'll work for them out of the box from which they can then dip their toes into the deeper waters, won't want to spend their time building up their own initial configuration and learning Emacs Lisp.

However, I think there are clear problems with this too:

1. Once someone reaches the edges of what Doom Emacs can provide for them, or help them do without using Lisp, the learning curve quickly shoots straight up, as they now have to come to grips with the still-alien world of vanilla Emacs.
2. At the same time, users trying to venture out of the cocoon Doom Emacs has offered them have to face the huge complexity of Doom Emacs and all of its subtle differences from what everything else in the ecosystem is set up to expect.
3. As a result, Doom Emacs users do not really become Emacs users. Instead, they stay isolated in their ghetto, occasionally emerging to request package authors add redundant information to their READMEs just for Doom users, but otherwise sticking to themselves, rarely even contributing packages to the ecosystem.

Ultimately, I'm not sure what to do about this, or even how bad of a thing it is, but Doom Emacs certainly feels like a soft-fork of the Emacs world, and I'm not sure I like the looks of that. I'm also not sure how much it's really helping new people actually join the Emacs community, instead of something related but also somewhat separate.