My Emacs Config Journey
At the end of the day, your emacs config is your own.
Whether your using an emacs 'distro' like Doom or Spacemacs, or writing your own config from scratch, all the code and state built up when you start emacs is something you should own and learn how to debug.
I have been through 3 or 4 rewrites of my emacs configuration, and have ended up on Doom Emacs. I've seen hit or miss experiences with Doom from fellow coders, and so far, the ones who have left Doom preferred to build their own emacs configs from scratch. I definitely recommend that! The experience will teach you all that Doom has protected you from, or what pain it caused you. In the end, whichever way you go, you'll be able to appreciate either that Doom has good coverage, or that if something goes wrong, it's your fault.
Rough outline of my emacs config journey - hopefully this gets more structured
attention over time:
Note that I came from a few years of building up a vim/neovim config.
An initial vanilla emacs config or two
The pains of learning some elisp and configuring via use-package.
My killer-feature at first (vs. vim) was M-x + Helm (fuzzy-finding for every interactive command! Discoverability!).
Discovered org mode, become obsessed
Why do we even have code files? Literate programming!
I moved my config completely into a single org-file, and org-babel-ed/org-tangle-ed all the things.
A vanilla basic emacs config, part 2
Ultimately the literate config felt like more prose than code, and I left it when I felt it was encouraging me to write more about my config more than actually fix the issues in it.
Also, order-mattering between org-babel/tangle blocks became annoying. I'm sure it's solvable, but at this point that felt like I was maintaining the wrong thing (my literate config tooling, rather than the config's features itself).
Doom Emacs
I've been here since late 2017, and have not wanted to leave.
It was chosen before adding more engineers to the team at work. The hope was to standardize, so that we could grow together across the team. It worked, sort of.
For developers coming from a general vim+plugins+tmux experience, Doom is well within reach - most things will just work, and the learning is about getting all the new emacs keywords and plugins integrated into memory. Ex: magit, helm, ivy/counsel, etc.
I've not really debated leaving Doom. Instead, I actually enjoy learning more and more of Doom whenever things go wrong. The community is strong - I enjoy seeing PRs that upgrade language configs to use the latest tools. It feels like my config is being maintained for free, cutting off problems that come from bad package updates or other newly introduced emacs bugs.
There are times where things go wrong, and you need to dig or search for the solution instructions. Mostly they are solved within a day by someone in the community, which is about how long it'd take me to figure it out anyway.
Backlinks
Emacs is a text-editor that is quite old, but has been worked on continuously since then.
Emacs is special because it is very dynamic. It is implemented in lisp, which allows interactive development via the REPL, giving you tons of power and control. It is a double-edged sword, in that you must take care to keep your systems running smoothly. Tools are everything, so keep your knives sharp.
Emacs can be very difficult to learn, especially in a vacuum. I hope to document the things that have been useful to me.
Some emacs notes:
I started writing a small bit to share in the org-roam slack #random channel, but it kept growing and growing, so I broke it out into an note here, which seemed a little ironic but mostly fitting. I hope to maintain and add to this over time - feel free to share any thoughts!
The context: Emacs Distributions (like Doom and Spacemacs) vs Vanilla configurations. What is recommended for new users?
Note: I've spent very little time in Spacemacs, so can't speak to it vs Doom. I'd naively assume the pros/cons of Spacemacs are roughly the same as Doom's.