Re: [Nmh-workers] A useless but interesting exercise: Design MH from scratch in the 2014 context

[Ralph Corderoy]

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.