>> 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 [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
