undefined

points

[-]

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.

by killix2 hours ago|

parent|

[-]

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

by fridder6 hours ago|

prev|

[-]

I'm also a Doom user, albeit a new one. What is making you consider the switch?

by quibono6 hours ago|

parent|

[-]

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.

by iLemming44 minutes ago|

parent|

[-]

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.