Avoiding Emacs Bankruptcy

I think these tips all make a lot of sense in realms far beyond emacs. Anywhere tech debt creeps in… Other editors, Linux desktop configs, software build tool systems, and software development itself. There something alluring about tweaking a system to be customized in a “perfect” but personally way… but it often only bites you in time. the longer I work with computers the more I appreciate resisting unnecessary connivance tweets, and learn to live with the defaults :)

One of the most painful tweaks I have made is switching to a non qwerty keyboard layout… this basically forced me to reconfigure loads of software, which all just feels like a mess of unnecessary work and maintenance. Especially since I use vi like bindings wherever possible and all vi mode defaults are qwerty based. I often consider scraping it all and going back to qwerty, but I’m not sure if I’m ready to relearn basically all my muscle memory for all software again. So for now I try to keep things the way they are, and resist adding complexity when possible.

Aside from what the article focuses on (being selective about which packages to install in the first place), I feel that making extensive use of the

(use-package ...)

macro keeps a large Emacs config manageable. It gives things a very standardised structure, as opposed to the config being pages and pages of arbitrary Lisp code of different vintages.

https://www.gnu.org/software/emacs/manual/html_node/use-pack...

This idea rhymes with an approach I term PC hygiene. I'm amazed by the sheer crunk and mud that the average Windows user has on their PC and I'm convinced that this is the reason why so many people have a miserable experience on it. (And to be fair, Windows does its damnednest to contribute to the rot.)

Starting with a clean install, removing as much as possible that isnt actively used, using only clean installers via something like chocolatey, and above all being extremely cautious about installing any new program, all contributes to hygiene. For example I know that Adobe Reader will spray junk all over my PC and generally be aggressive about processes, reg keys, etc, whereas SumatraPDF wont. So Sumatra gets installed.

I really like this article's suggestion to leverage plugins instead of custom code, and to look carefully at what _modern versions_ of your software (editor, shell, etc) have feature parity with.

This mirrors something I noticed recently when snooping on a friend's dotfiles repo. I have this unholy collection of things that make sure bash saves my history, my prompt Doesn't Suck, with helps git/etc/etc -- and it's a nightmare because I have yet to untangle it enough to post on github. In contrast, my coworker uses zshell, and uses a plugin for it that basically adds _nearly everything I might want_ out of the box, and as sensible defaults, so their config is much simpler and easier to get started.

I use Doom[1], which is put together by people who know a heck of a lot more about Emacs than I do. Almost all my configuration is just turning on the features I want. Maybe once every year or two I check that my configuration is using stuff that has be superseded. This is super easy to use, gives me a great Emacs experience, and takes almost no work to maintain.

[1]: https://github.com/doomemacs/doomemacs

I built a starter kit [1] with this in mind: how can I leverage built-in functionality to the max? The stock setup installs only one package (`which-key`—now going to be included with Emacs 30!) and all other packages are opt-in. There's no framework: you just clone the starter kit once and tweak to your liking. I use this setup on most of my machines and I find it works pretty well.

On my personal machine, I have +2,600-line `init.el`. Fortunately I understand everything in there and I routinely modify it. It's been a long time since I declared bankruptcy. The built-in `use-package` macro really helps keep config tidy.

[1]: https://codeberg.org/ashton314/emacs-bedrock

> Recommendation: Use the built-in (vertical-fido-mode). If you want something more, look into Vertico.

I dunno about fido-mode, if I were to recommend a built-in completion package I'd rather say icomplete is better (using icomplete-vertical-mode). It has the neat lazy-completion feature that Emacs and Zsh have where I can type '~/.c/r' and it shows me all possible completions (so both '~/.cache/rofi.druncache' and '~/.config/rofi/config'), rather than eagerly completing on the '.c/' and leaving me stuck in '~/.cache/'.

That being said, I don't see the problem with declaring config bankruptcy, it gives me the chance to avoid making old mistakes in exchange for making exciting new mistakes, which I can learn from.

Three years ago I realized I had hit the same point. My .emacs file was about 500 lines long and many of the options dated back to 1997 when documentation of why you’d want to do something was sparse.

I rewrote it all using org-babel and use-package. It’s even longer now, but each package has documentation of why I’m using it and how. It makes life much easier.

I recently rewrote my 15 year old and very long/unmaintainable config. The main thing I did was break up my config into separate files per major mode. All package installation is in one file though, because minor mode packages are shared between multiple major modes.

That just solved the maintenance and editing problem. Each major mode only takes 5-100 lines of config. Lots of major mode specific custom code, but now I know where to look if something is off. Reasonably simple to evolve.

IMO, the real headache is installing the supporting binaries ripgrep, fzf, lsp, tree-sitter, native-compilation, etc. I agree that emacs config should hew as close as possible to the defaults, and my init.el is pretty small. For the binaries, I build a docker container and run emacs in it. https://hub.docker.com/r/wwarner/emacs-gopy

>packages interacting poorly in hard to diagnose ways

That's a problem of uncontrolled mutability and lack of type signatures. It's a common problem in python, ryby, javascript, emacs lisp and many others.

Emacs can run Rust, and it could be solved in the future, but i don't know what's going on with the GPL license. Can one make a dynamic module and use for example the tokio library in emacs when tokio is not GPL?

I had this problem a few times with Vim — installed too many plugins and custom scripts, things breaking at random times, slowdowns that are hard to diagnose.

That's why I now just use VSCode with nvim emulation instead.

I comment every line of my neovim configuration no matter how obvious it seems to be at the time. I assume when documenting that I won't remember what that config name does. Would that work for emacs?

I think it's fido-vertical-mode not vertical-fido-mode.

I find rm works great as a tech debt buster