Indeed. I myself am on Doom Emacs but I've increasingly been thinking of moving over to vanilla Emacs. I'm a bit worried about the transition period due to all the keybind differences but I'm sure it's not too bad.
Indeed. I myself am on Doom Emacs but I've increasingly been thinking of moving over to vanilla Emacs. I'm a bit worried about the transition period due to all the keybind differences but I'm sure it's not too bad.
Tell your agent what parts of Doom Emacs you actually use, and ask it to build a minimal init.el containing only those parts. You're probably only using ~2% of Doom, so the resulting init.el will likely only be a few hundred lines, and most of those lines will be comments and key bindings.
It won't be a perfect transition, but it will make it a lot smoother.
Done this exact thing. Fed an agent my actual keybindings and `M-x` history, let it regenerate a lean init.el. Two notes from the other side of it. It's great at the 2% you named, but it silently drops the muscle-memory stuff you never think about: which-key, the half-configured LSP, that one hydra. Diff the old and new against a day of real editing, not against your memory of what you use.
The bigger thing. "Ask the agent to build it" is fine here because init.el is read-only damage. Worst case it writes a file you `git diff` before trusting. That's the safe end of the spectrum. The instinct breaks the moment the same agent is touching things you can't cheaply inspect: package installs, shell-outs in a hook, anything with a side effect off your disk.
The lesson I keep relearning building this stuff: an audit log after the fact tells you what broke, it doesn't stop it. What you actually want is a capability check before the agent acts. This run is allowed to write `~/.config`, not to curl-pipe-sh. Plus a trail you can't quietly rewrite later, a hash chain, not a log file anyone with write access can edit. For an init.el that's overkill. For an agent you'd let near `apt` or your dotfiles repo, it's the whole game.
https://orkia.dev/r/e7aae397
I'm also a Doom user, albeit a new one. What is making you consider the switch?
Don't get me wrong, I'm loving Doom and have used it full time for a few years now. But over time I've started being uncomfortable with the fact that I don't fully understand the editor, don't fully appreciate the difference between what comes in as part of vanilla Emacs and as a Doom feature, and I feel like I am depending on a huge bunch of code and configuration I might not really even need.
Selfishly I wasn't willing to spend the time to master Emacs proper back then, but with the LLM craze now I find it much easier to hack on my configs.
I've had multiple config bankruptcies over the years until settling down with Doom. I'm considered "experienced Emacsian" - built and published packages, etc. I'm still using Doom but only the core of it. I don't even consume almost any of its "official" modules - I have my custom ones instead. I have considered building my own config from scratch (yet again), but I like Doom's core macros - map!, add-hook!, defadvice!, undefadvice!, etc. I'd probably inevitably end up borrowing them and structuring my new config just like I already have, so I see no point.
> I don't fully understand the editor
Going vanilla will not help you there - well, not completely anyway. Moreover, it may even obscure some features that were easily accesible before.
> I don't fully appreciate the difference between what comes in as part of vanilla Emacs and as a Doom feature
That is not very difficult - learn how to use built-in features - profiler, edebug, describe-, apropos-, hooks and advising, etc.; Start writing Elisp code (with understanding it). In the end, it won't really matter - whatever runs in your Emacs, there's always a way to get to the source. And if you ever need to disable any feature of Doom - there are multiple ways to do that.