I understand that some people find that useful, but I have not yet
been persuaded that it is nmh's job to provide an interface for
generic Unix text processing tools.
That was there, whether by design or accident, from the start. And I
suspect it was clearly by design. Regardless, it's part of the de facto
contract with MH users. I found that paper I was asking about, in nmh's
git. :-) This is the one that started me using MH.
http://git.savannah.gnu.org/cgit/nmh.git/plain/docs/historical/realwork.pdf
says
That is, the directory- and file-structure of UNIX is used directly.
As a result, any UNIX file-handling command can be applied to any
message.
I will note that is one paragraph, and the practical use of that feature
is not really mentioned (other than composition) in any of the original
MIME papers. That's why I asked Norm about that; his answer was, basically,
"We didn't really think much about that part" (although I am sure Norm
will feel free to correct me if I am misrepresenting him).
As for the message store being part of the de facto MH contract ...
maybe, although perhaps we're arguing about the fine print. Exactly
WHAT does that contract say? If the contract says, "Hey, each file
contains a single, complete RFC-822 message", then we're meeting the
contract and no one has proposed to change it.
If the contract says, "All text content shall be accessable by traditional
Unix tools regarding of the MIME encoding" ... well, I'd be rather skeptical
of that, since MH predates MIME by a number of years. None of the people
who added the rudimentary MIME support the MH (or nmh) felt like changing
the message store, although it's very probable that at least in the MH
days they did not envision the vast majority of messages NOT being
text/plain. So I think MIME has blown up the fundamental underpinnings
of the original MH de facto user contract and I don't personally feel
bound by it anymore. But I'd be willing to be persuaded otherwise!
Also, it's hard for me to get excited about writing a bunch of code
that will make nmh more complex for no gain to nmh.
It seems we're struggling with how to handle MIME replies within the
closed ecosystem of nmh. Almost as if it were a monolithic MUA.
Well ... I take your point, but I don't think changing the message
store really would help for replies. To me the issues there are:
- How do we "process" MIME parts of the replied-to message to generate
the reply template? This is sort of what I was talking about on the
thread with David; how do we specify this in terms of UI, configuration
files, etc etc?
- How do we then take these "processed" MIME parts and compose a MIME
reply?
The underlying store doesn't really matter, as I see it, for these two
operations.
If composition took a similar directory hierarchy as the draft, that
directory could be built-up piecemeal, partially with nmh's help, e.g.
repl(1), but also with normal Unix commands for the more unusual uses.
As needs become clearer through use, nmh can gain some of the more
common operations itself.
Well, I could be persuaded that this makes sense for composition. That's
an interesting idea ... you could build up a directory in the "right" format
and have it read by mhbuild. What do other think of that?
--Ken
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers