Emacs is paradoxical — it always works, yet at the same time, any parts of your config may prove to be broken at any given moment. Maintaining a complex Emacs config is a chore. And not because of Emacs itself, core of Emacs is remarkably stable, most issues are in the customization layer you control.

What you get in return though is far more valuable than any alternative — when something breaks, YOU can fix it. You're not waiting for a vendor or update. The system is transparent and malleable. Each fix teaches you something. Over time, you build deep understanding of your environment. The chores become easier. Unlike rigid software, Emacs molds to your exact workflow. The maintenance cost pays for a tool that works EXACTLY how you think.

Emacs is a professional chef's kitchen - A chef maintains their knives, adjusts recipes, deals with temperamental ovens. More work than a microwave dinner, but they can create ANYTHING. When the soufflé fails, they know why and can fix it.

"Yeah, well", some may say, "I don't want to be a chef, I just want to occasionally fix some bad cookies, using the 'easy-cookie-maker-kit', it just-works™, why not use it?".

I can tell you my perspective on that. I decided to "become a chef" and use "my own kitchen", because I'm tired of different types of cookie-maker-kits. It seems like everyone has a different opinion of what the cookie-maker-kit should look like, what it should do, what kind of cookies can you make with it. Every few years, the "ultimate" kit appears, promises to revolutionize cookie-making, then gets abandoned or dramatically changed. Your muscle memory becomes worthless. Your recipes need rewriting. The new kit can't make the cookies you loved.

But in my kitchen? My grandmother's rolling pin still works. The oven I learned five years ago still bakes the same way. When I discover a new technique, I add it to MY repertoire, not wait for someone to maybe include it in Cookie-Maker-Kit 3.0. Sure, I burned a few batches learning temperature control. Yes, I maintain my tools. But now I can make cookies, and bread, and soufflés, and things that don't even have names yet.

The cookie-kit users are still arguing about whether round or square cookies are "correct," while I'm over here making star-shaped ones because I felt like it today.

>Maintaining a complex Emacs config is a chore. I have given up and adopted Doom Emacs. Let cleverer people do the wrangling

I feel like Doom is maybe obsolescent on account of standard out of the box emacs having fairly easy to set up these days, with themes and LSP and etc just there out of the box and package-install just working.

But also I have absolutely zero desire to run with modal keybindings, which seems to be Doom's schtick.

No, Doom is not a final product of some sort. Going back to my "kitchen" analogy, Doom is like a recipe book - it's great for some ideation (you can check for example what kind of things used in Python module and build your own, or extend existing, 'official' module). It offers you some modularity - Doom-based configs are great for breaking down into reusable components. Doom's core also contains a lot of very nifty macros that allow you to reduce otherwise unavoidable boilerplate. Other than that, Doom is just the regular, good old Emacs - you still can do everything you could do before, with perhaps some better structure and code ergonomics.

Doom may become obsolete only if it keeps partitioning into separate packages, e.g., doom-modeline started as a core component of Doom, now it's a separate package. Similarly, nothing really preventing anyone from forking other core parts of Doom into separate packages.

Also, evil-mode keys are optional, anyone can use Doom without using vim keys, there's still good value in doing that.

That's also why I don't use it. It's not bad at all! It's just not how I want to use Emacs. It's not right for me.

I sure do get the appeal of an out-of-the-box Emacs setup that does everything with modern defaults, but the base installation gets better, more ergonomic, and more powerful by the year on its own.

"out-of-the-box Emacs setup" was never a thing that lured me into trying it. I liked the idea of modularity with Doom. Before that I never knew where to put things, how to split them, how to make them work with one another, how to disable features without breaking some others.

I have learned tons of things since then and on multiple occasions I thought about rebuilding things (with my now more extended knowledge) from scratch, but I'm afraid I will inevitably end up borrowing some core Doom macros, and end up recreating something that very much looks and feels like Doom, without being Doom, perhaps with a different package manager. That I believe is the only non-negotiable part of it today. Other than that, Doom is nothing but a very thin layer of abstraction. I don't even use Doom's own modules, instead I built the set of my own. Anyway, if you ever feel overwhelmed and decide to call another emacs.d bankruptcy, maybe give Doom a try. You can disable all the modules and build on top of that lean core, it still has objectively nice features - CLI tool is nice, macros like map! and add-hook! and defadvice! are very cool. It loads extremely fast, etc.