CustomizationSensibleLimits

Created on November 12, 2023 at 11:38 am

Recently, for reasons beyond the scope of this entry, I’ve been mostly handling my email in GNU Emacs PRODUCT , with MH-E. GNU Emacs ORG is famously flexible and customizable, mostly through the somewhat challenging method of ‘merely’ writing the relevant (Emacs) Lisp code to do what you want. I’m capable of writing Emacs PRODUCT Lisp, so armed with a hammer and using a new mail client, I have been finding plenty of things to use that hammer on (sometimes with hackery and Emacs crimes). At this point, I’ve accumulated something like 1500 CARDINAL lines worth of customization (although that includes a lot of comments), and I can think of more things that I might do.

(Some of this customization is because MH-E doesn’t quite do what I want it to do, sometimes it’s because I want a more convenient way to do what it already can do inconveniently, and sometimes it’s because I’m trying to recreate features I’m used to in exmh.)

Several years ago DATE I read Tobias Bernard’s PERSON Doing Things That Scale. To summarize the article badly, Tobias Bernard PERSON talked about how they had moved away from customizing things (and then having to maintain the customizations) in favour of doing generally useful changes to upstreams. This argument gave me tangled feelings that I’ve yet to sort out enough to write an entry here about, but part of it is certainly on point. Every customization I make to my Emacs and MH-E PRODUCT setup is effort to write, effort to remember, and effort to maintain. Do I actually need an ultra-hyper-customized MH-E PRODUCT environment? Am I going to even use all of these hacks I’ve done? Both clothes and mail clients can be comfortable and useful without being form fitting.

Of course, this is a personal version of something that I run into all of the time professionally, as a system administrator. There’s a lot of custom scripts, custom Prometheus ORG metrics exporters, custom web things, custom mail system features, and so on that we could write and put into production, but all of them have both a cost and a benefit, and sometimes the costs are not worth the benefits. Just because we can do something doesn’t mean that we should. At the same time, sometimes we should, even if the customization is large and thus the costs are significant.

(For example, we have a bespoke custom ZFS ORG spares system, which was a chunk of work to write and tune, but on the other hand has been rock solid and lets us basically not worry about disk problems. And our very custom simple mailing list system is quite appreciated by our users, although the Exim configuration involved is surprisingly complex.)

I don’t have any particular answers, either for my sysadmin work or for my GNU Emacs PRODUCT hacking. But I do want to think about the question at least a bit, even (especially) for my own GNU Emacs PRODUCT coding. Just because something is an interesting Emacs PRODUCT Lisp problem doesn’t mean that I should solve it, especially if I’m currently immersed in solving Emacs PRODUCT Lisp problems. And just because I can tweak and customize something doesn’t mean that I should.

( Solving Emacs Lisp WORK_OF_ART problems is a little bit addicting for me, much like any programming. Sometimes I have to pull myself away from the urge to do a bit more and then a bit more and so on. Hopefully this urge will pass.)

Connecting to blog.lzomedia.com... Connected... Page load complete