Wandering Thoughts archives

One of my MH-E customizations: 'narrow-to-pending' (refiles and deletes)

I recently switched from reading my email with exmh, a graphical X frontend to (N)MH, to reading it with MH-E in GNU Emacs, which is also a frontend to (N)MH. I had a certain amount of customizations to exmh, and for reasons beyond the scope of this entry, I wound up with more for MH-E. One of those customizations is a new MH-E command (and keybinding for it), mh-narrow-to-pending.

Both exmh and MH-E process deleting messages and refiling them to folders in two phases. In the first phase your read your email and otherwise go over the current folder, marking messages to be deleted and refiled; once you're satisfied, you tell them to actually execute these pending actions. MH-E also a general feature to limit what messages are listed in the current folder. In Emacs jargon this general idea is known as narrowing, and there's various tools to 'narrow' the display of buffers to something of current interest. My customization narrows to show only the messages in the current folder that have pending actions on them; these are the messages that will be affected if you execute your pending actions.

So here's the code:

(defun mh-narrow-to-pending ()
  "Narrow to any message with a pending refile or delete."
  (interactive)
  (if (not (or mh-delete-list mh-refile-list))
      (message "There are no pending deletes or refiles.")
    (when (assoc 'mh-e-pending mh-seq-list) (mh-delete-seq 'mh-e-pending))
    (when mh-delete-list (mh-add-msgs-to-seq mh-delete-list 'mh-e-pending t t))
    (when mh-refile-list
      (mh-add-msgs-to-seq
       (cl-loop for folder-msg-list in mh-refile-list
                append (cdr folder-msg-list))
       'mh-e-pending t t))
    (mh-narrow-to-seq 'mh-e-pending)))

(This code could probably be improved, and reading it I've discovered that I've already forgotten what parts of it do and the details of how it works, although the broad strokes are obvious.)

Writing this code required reading the existing MH-E code to find out how it did narrowing and how it marked messages that were going to be refiled or deleted. In the usual GNU Emacs way, this is not a documented extension API for MH-E, although in practice it's unlikely to change and break my code. To the best of my limited understanding of making your own tweaks for GNU Emacs modes like MH-E, this is basically standard practice; generally you grub around in the mode's ELisp source, figure things out, and then do things on top of it.

There are two reasons that I never tried to write something like this for exmh. The first is that exmh doesn't do anywhere near as much with the idea of 'narrowing' the current folder display. The other is that I wound up using the two differently. In MH-E, it's become quite common for me to pick through my inbox (or sometimes other folders) for messages that I'm now done with, going far enough back in one pass that I wind up with a sufficient patchwork that I want to double check what exactly I'm going to be doing before I commit my changes. Since I can easily narrow to messages in general, narrowing to see these pending changes was a natural idea.

(Picking through the past week or more of email threads in my inbox has become a regular Friday activity for me, especially given that MH-E has a nice threaded view.)

It's easy to fall into the idea that any readily extendable program is kind of the same, because with some work you can write plugins, extensions, or other hacks that make it dance to whatever tune you want. What my experience with extending MH-E has rubbed my nose into is that the surrounding context matters in practice, both in how the system already works and in what features it offers that are readily extended. 'Narrow to pending' is very much an MH-E hack.