So again, I think that the UI issues and message store issues are independent. I'm personally much more interested in the UI issues. As I've said before, the ability to scan/next/prev/show attachments would do it for me. This wouldn't be too hard to add to the current UI. Oh, and the ability to show an attachment to stdout. I'd work on it if I had time.
I don't want to mess with the message store because of the number of tools that people have written that count on that format. And, I don't think that it needs to be changed. Many years ago I added the hooks interface to nmh. Hasn't been as controversial as my attachment handling stuff, which makes me think that it isn't widely used. The hooks interface allows you to specify programs in your profile that get invoked when messages are added/deleted/refiled. I use these hooks to build a separate searchable database. I have a number of additional command line utilities that operate on this database. Any of you could use these hooks to maintain a separate directory tree that stores mail in a format that you prefer, such as one directory per message. And, I suppose, you could construct scripts that would pluck attachments from that tree. You could use the hooks to prototype your ideas for other storage formats. Probably less than an hour of work. I would point out that a minor problem with this approach, which would also exist if nmh were to change storage systems, is making sure that the subsidiary files are synchronized with the originals. I have (and nmh would need) a fsck-like utility that checks and fixes this stuff. Problems don't often arise, but a disk-full or system crash at the wrong time can mess things up. Jon _______________________________________________ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers