Thank you, that's helpful, and I recognise a lot of the pain points and pluses there. I started with Doom, loved it, but wanted to understand Emacs better so e

Thank you, that's helpful, and I recognise a lot of the pain points and pluses there. I started with Doom, loved it, but wanted to understand Emacs better so ended up writing my own config. I now understand Emacs a _little_ more, I know what every line of my config is doing, and there isn't an extra layer of abstraction or opaque bash commands I have to periodically run. I also feel more comfortable that Emacs with a home-grown config will last me 10+ years. It's incredible what Henrik has achieved and the level of dedication and support is astounding, but I wonder how sustainable it is as the community inevitably grows. Rolling my own setup has certainly made me appreciate Doom a whole lot more, though. And it's hard to shake the feeling that I could spend a year or two just hacking on Emacs to get half of what Doom offers. It's like the trap of wanting to get into game programming and finding yourself writing a game engine instead of a game. (I picked up Emacs to learn Clojure and other Lisp dialects better.) It's also a little silly to have an expectation that I need to understand everything that Doom does behind the scenes. I don't have that expectation with Emacs itself, or with IntelliJ or vim, or VS Code… Maybe the answer is to just read the (smallish) Doom codebase to understand it better and contribute however I can, be it in Discord, with cash, or PRs. And get back to hacking instead of hacking Emacs…