Linux Maxxing dot com

Rewriting my Emacs Config

In my last post entitled “RETVRN to Emacs” I described a bit of my recent foray back into GNU Emacs. Despite using my own config (after using Doom Emacs for a short time), it had been so long since I used Emacs that I had zero strong opinions on any of the packages or configuration. So I decided to change that. When I dive into something, I tend to go on a head-first deep dive with a millstone tied around me. Maybe not the best way to describe it considering certain passages, but it’s accurate.

As I dug through my init.el, I realized there was a ton of functionality that I no longer used, and my inconsistent package syntax was sloppy at best. It was a mash-up of use-package and conventional commands, the result of copypasta from both old and [more] modern solutions found on the internet. For some of the packages I did not remember why they were there or where I originally found inspiration for them. And the videos I watched to help write my init.el are all now 4-5 years old. Surely there have been changes to Emacs.

There have been changes to Emacs.

It turns out Emacs has changed a lot since I last used it (which I believe was the tail end of version 27 when I wrote my config). A ton of features are now built-in: use-package, which-key, fido-mode, project.el, and treesitter to name a few. Many small packages were absorbed or made obsolete by Emacs built-ins (e.g. hide-dotfiles-mode package for dired). Ivy and Counsel still exist, as does the older Helm, but has largely been replaced by Vertico/Orderless among the hoi poloi. These, like many other modern Emacs packages, extend upon built-in functionality rather than reinventing the wheel with separate frameworks like Helm, Ivy, and Counsel.

One of the best Emacs references is the book and blog Mastering Emacs. The author goes through most of the core functionality of Emacs in enough detail to be thorough but not to the point of overwhelming a new user. You’ll be surprised what is already built-in.

Example: Completion

Here’s an example of my thought/discovery process for completion:

Since I want some kind of completion framework, I started with bare-bones ido mode. This is good to know anyway when you inevitably have run a clean config because of an error. Ido mode adds completions for switch-to-buffer and find-file, which is not enough for me. Then I added in the relatively new fido mode which adds completions to the minibuffer with flex matching, and has effectively superseded ido mode (thought ido is still included). I disabled fido mode and enabled only icomplete-vertical-mode. When configured this can be used to get similar functionality to fido-vertical-mode without flex matching. Then I added Vertico, Orderless, Marginalia, and Corfu in order to see what those popular packages give me.

After testing and configuring all of these options, I’ve settled on the built-in fido-vertical-mode because I like flex completions, and configuring in-buffer completions (but not point completions - completions show up in a separate minibuffer) so that completions are shown in a minibuffer but are not selectable (found it a bit clunky). This combo has all the functionality I need from Ivy/Counsel, and the built-in Emacs completion framework is suprisingly customizable. I have no need for the slimmer (relative to Ivy/Counsel) Vertico, Orderless, Marginalia, Corfu, etc, though I do concede they could add value. Corfu does still seem to be the best route for point-completions if you want that, I just found the built-in minibuffer completions to be good enough. The reality is that I’m just so good and tpynig that a rboust cmopltetion framweork is not smoething I need. The lesson in all that is you’d never even know this if you only go through one of the older Emacs video series from SystemCrafters, distrotube, etc.

Another example: themes. The built-in modus themes are on another level. I generally gravitate toward dark-purple/blue themes like palenight, onedark, tokyonight, etc, and also have a huge love for gruvbox because of how easy it is on the eyes, even if it sometimes looks baby-green (parents know what I mean). The Modus themes are in the same vein as palenight/onedark but are incredibly customizable and readable. On first load, modus-vivendi-tinted was passable but not my favorite. After spending some time with it, researching the excellent documentation, and making it work for proof-of-concept, I’ve found I really like it. Customizing takes some work, but that’s part of the fun. The point is that I would not have discovered this unless I deliberately gave built-in functionality a try.

I’ll also add that a similar theme to Modus-Vivendi can be found on Vim: zaibatsu default colorscheme with only a few tweaks (background color, etc).

In short time I have basically rewritten my Emacs config and done so in a way that is much smarter imho. And I’ve learned a ton of the nuts-and-bolts of Emacs. In another post I’ll go through my config line-by-line-ish, but for this one I’m just going to share some principles I’ve adopted in writing my config.

My Guidelines for Writing My Emacs config:

  1. If you’re short on time, Doom and other pre-built configs are far better than a quick, franken copypasta’d “custom” config.
  2. Avoid copying old (or any) guides.
  3. Identify the functionality you need and base your package selection off that.
  4. Know the built-in solutions first.
  5. Look at alternatives before selecting one.
  6. Be consistent with package calls, i.e. either utilize use-package or don’t.
  7. Use early-init.el.
  8. Split your init.el into multiple files.
  9. Literate configs should not be necessary.
  10. Evil-mode: use evil-collection and general.
  11. Custom keybindings should be completely unique for functions without existing keybindings.
  12. Custom functions should be identifiable as custom.
  13. Create an additional static “rescue” init.el facsimile with bare-bones built-in configuration.

In another post I’ll go into detail each of these points, and perhaps add to them. For now, ponder them for yourself and develop your own interpretation or opinion about them. These are my opinions, you may (and should reasonably) disagree with them.