Sounds great! I have one comment about your naming scheme, though:
mhn -show -> mhshow
mhn -store -> mhstore
mhn -list -> mhlist
This would be a little confusing, I think, since the distinction between
(the existing) "show" and (the new) "mhshow" is not that one of them belongs
to or works with MH and the other doesn't, but that one groks mime and the
other doesn't. So a better prefix than "mh" would be useful, although I'm
not sure what it would be.
Well, you may never see the mhshow command, since it is just a
transitional command. It's only purpose is to give me a place to put
the code to display MIME messages, while I'm cleaning things up.
Depending on how the work goes, I may merge "show" and "mhshow" before
any of this is released.
I understand the motivation of using a prefix like "mh", which would avoid
conflicts - I'd be very surprised if there isn't already an executable out
there somewhere named "mimeshow", for instance - but then, the MH commands
that already exist aren't all that careful about not chewing up valuable
chunks of namespace, and fixing that would require non-backwards-compatible
changes.
Since several of the MH/nmh commands already use the "mh" prefix, it
makes sense to use that.
Anyway, this sounds like a great idea in general. I'm assuming after all
is done there'd still be flags to give to eg "show" to prevent MIME
processing and just spit the raw RFC822 message to standard out, right?
Yes, I will leave a way to cat the raw RFC822 message to stdout.
--
Richard Coleman
coleman(_at_)math(_dot_)gatech(_dot_)edu