2023-12-26
Maybe learning to let new environments be themselves (more or less)
I've been using exmh to read and handle my email for what is now a very long time, and I'm completely used to its specific features and behaviors. Or rather that was true until very recently, when for reasons beyond the scope of this entry I switched more or less completely away from exmh to MH-E in GNU Emacs. Me being me and GNU Emacs being GNU Emacs, this immediately set me off on an extended process of customizing MH-E to work better for me.
When I started on this journey of customization, my more or less implicit goal was to reproduce as much of my exmh environment as possible in MH-E. It was the productive environment I was used to and had a lot of experience with (and had customized significantly). If I had to give up exmh for latency reasons, I at least wanted something that was as much like it as possible, including several idiosyncratic exmh features. This was a somewhat awkward process, since GNU Emacs doesn't work like exmh, or even like Tcl/Tk; there are various things that are easy and natural in Tcl/Tk that are rather awkward in GNU Emacs, like buttons and menus. I also mostly set MH-E's customizations to work like exmh, for example preferring the plain text version of email over HTML.
A certain amount of this was, in retrospect, somewhat of a mistake. I've written some code to imitate exmh behavior as much as possible that I've never actually used outside of testing, because the imitation isn't all that good. Some of my substitutes for exmh features are perhaps unnecessary clutter, even if they work and I use them sometimes. And MH-E has its own strengths that have changed how I read email, which has led to me modifying how various pieces of my NMH infrastructure work to improve my experience in MH-E. I've also more or less adjusted to MH-E's key bindings instead of exmh's. And after I stopped trying so hard to make MH-E like exmh, some of what I did was to actively improve MH-E features in a GNU Emacs way (such as better folder name completion for my tastes, or augmenting existing MH-E features); I might have been further ahead if I'd started with them.
(I'm also glad that I didn't try to go further down a rabbit hole of trying to make Tcl/Tk like buttons and so on in GNU Emacs, which I was tempted by at one point. Honestly, that was partly decided by seeing how comparatively unresponsive many GNU Emacs UI elements already are. Basic GNU Emacs text rendering may be faster than exmh even with latency issues, but some other things are clearly worse, possibly for internal Emacs structural reasons.)
On the whole, I think I would have been better off if I had started out trying MH-E on its own merits and its own terms, rather than attempting to turn it into an imitation of exmh. There's certainly things I've added that are useful and that are similar to exmh (and ideas I've taken from exmh), but there are also things in MH-E that I passed on for too long because they didn't match my exmh expectations. For example, MH-E has significantly better rendering of HTML email, so I no longer set MH-E to prefer plain text parts.
This is probably not the first time I've tried to make a new environment imitate an old environment, and it's basically certain not to be the last time. Perhaps next time around I can try out the lesson I sort of learned this time around, and start out by letting the new environment be itself.