. * \|/ . o -*- o + o .
o + --*-- * . ' . * . o , . o
. . /|\ + . + . -*- .
. * - o ' . *
- ·:· * . * . * o
2024-12-16
Jack Baty's post "Emacs from scratch once again"
rethinking an entire set up from scratch (with enough time on one's hands), can be extremely fun and rewarding.
https://home.hedy.dev/posts/starting-afresh/
(gemini version)
I had a similar story to Jack's for my vanilla emacs config. when I started out, I was simply curious to poke into the rabbit hole that is emacs. I had come from vim and neovim. I looked around, it seemed that customizing anything to be "satisfactory" (by my... overly high standards in retrospect), required a lot of elisp, and a lot of troubleshooting. to make matters worse, I had recently switched to MacOS, and was unfamiliar with where things were like linux, where things were inherited from BSDs and where things were completely foreign. Getting Evil to play nicely wasn't easy either.
Then came Doom Emacs: since it's a distribution, I thought it should account for multiple platforms and environments so I didn't have to deal with configuration as a major blocker to try the rest of emacs. Doom was deemed as "a good vim config for emacs", perfect for my needs at the time.
Doom had a configuration of its own -- several files even. one of these is for Doom "modules", sets of configuration for a particular purposes, such as a file format, a different keyboard layout, a preconfigured emacs package, and so on.
being able to toggle a line comment to enable and disable modules was a huge plus. I could quickly try out the best of the emacs ecosystem -- org-mode, latex rendering with SVG[^1], EWW, magit, LSPs, tree-sitter, and all that jazz.
[^1]: boy, was this a rabbit hole of its own.
the idea was (as I understood it at the time), that when you want to use a particular emacs package, rather than using the usual package manager and look into integrating that package into your Emacs, Doom had preconfigured it for you and have tested it to work well with the rest of Doom. you can then simply enable that package, adjust some config options exposed by Doom, and it will "just work".
well, some didn't. before this, when I wanted to customize a package I can simply use C-h or lookup the package's documentation. now, I have to not only do that, but also look at what Doom has customized, whether Doom as a config option of its own for it, and whether there are open GitHub issues on its repo for my problem.
I decided it was time to go back to my own vanilla emacs. thanks to Chemacs[^2], I was able to run both simultaneously.
[^2]: iirc, emacs only supported a custom config location starting version 29.
I could take inspiration from Doom's tried-and-tested config and copy over what I want to keep into my own config.
since I was starting over, I could choose a different package manager. I didn't have such a good experience with straight.el, I went with something new and shiny, elpaca. I started my config when emacs 29 was just released (Doom had a hard requirement of >= 27, <= 28, iirc). it featured built-in eglot (LSP), tree-sitter, and emoji completion, all of which saved a lot of lines of config. I could also reconsider the completion. Doom used company, I decided to try something different, something more lightweight; I went with Corfu and Cape by Daniel Mendler. it was easy to wrap my head around, even if the underlying workings may be complex and hidden well away; I even ended up contributing patches to some of the packages I used.
similar to Jack, I also referenced some other configs and had great help from Prot's blog posts. Doom was still faster than my emacs config now, but I didn't mind. I understood what my config did and knew what to look for when something stops working. thanks to some good folks on mastodon, I started considering emacs as graphical application rather than something I open when I need to edit, and close it when I'm finished. comparing start up speeds with neovim was unproductive.
some time later, I had enough with Evil. it's true that I felt more at home with it, but I could work with things like nano just fine on systems that poses that limitation. evil didn't play well (without excessive customization) with the rest of the emacs ecosystem either. I've since eliminated all evil from my system and never looked back.
the only thing I miss was locking completion-related keybindings[^3] to Evil's insert mode. but removing Evil (cue: bold heading in italics "Starting Over"), I decided that I didn't need them after all. I could just M-x when I need them.
[^3]: I don't use auto-completion, only manually-triggered completion, and a "corfu-candidate-overlay" package that gives me a tiny nudge (which I accept with a <tab>) when there is only a single completion candidate available. as of writing, there is no equivalent I am aware of in the neovim ecosystem for this.
one last thing that made it easier to work with vanilla emacs was that I stopped trying to make it work on multiple platforms. if I ever do want to try get it working on a linux box, I have provided a "local-init.el" option where I can add local customizations without tracking it in dotfiles, inspired by my shell and git set up:
https://home.hedy.dev/posts/multiple-emacs-git/
(gemini version)
I still keep my Doom config around for testing these days. both it and my config for emacs are available for perusal on my dotfiles repo:
https://github.com/hedyhli/dotfiles
***
replies:
https://gemini.envs.net/x/redterminal.org/gemlog/2024-12-16-re_Emacs_from_Scratch.gmi
(original Gemini version)
' ` ` ` ' ` ` ` ` ` ` ` ` ` ' ` ` ` ` ' ` ' ` ` ' ` ' ` ` ' ` ``