Hi Ken, > 1) The message store (1 file per message), instead of one file for the > whole store. > 2) Individual commands to perform message operations, as opposed to > traditional monolithic MUAs.
I've stuck with MH because it's both. Either on its own may not have kept me over the decades. > But I believe the answer is 2). To me the power of MH is using the > individual commands, which lets you do scriptable operations from the > shell, and also enables the front-ends that have cropped up. What you seem to be saying is that instead of an MUA where you are in its own shell, e.g. mail(1), you have an MUA comprised of many commands, scriptable with a bit of shell control-flow, but no commands outside the MUA's set should touch the storage. I want to find emails partially by email metadata but also by using Unix's toolset on them, e.g. I'm sure there was a email from Tom, copied to Dick, with a tar file containing a PDF produced by his new typesetter; pdfinfo(1)'s output would come into play. pick(1) or its replacement isn't enough alone, nor should it insist I stay within its confines by adding find-like -execs. > If your model is you want people to have to look directly in the store > to copy out PDFs that people send to you ... well, that just seems > like it sucks to me from a UI perspective. For common operations, MH can offer convience in accessing the store, but it shouldn't be off limits and the current format is inadequate in the MIME world. > I guess I'd want to know what people want to happen when they "show" a > message with some images or PDFs attached to it. Let's figure out > what UI people have in their minds and work from there. MH is two things as you pointed out. Yes, figure that out but the UI is just one half. Cheers, Ralph. _______________________________________________ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers