> As I've stated earlier, I haven't had a problem with the way that things > are so I'm not motivated to make changes. For those who are motivated, > I suggest the following: > > 1. Add an -attach option to mhbuild that is similar to the one that I > added to whatnow and send. If set, mhbuild will process attachment > headers in addition to the mime-composition file body. This is a > bit tricky because the whatnow attach code treats the message body as > a normal file, but should work because the user will either be > invoking whatnow mime or automimeproc which will mhbuild the message > before it gets to the send attach code.
Great. That takes care of send invoking mhbuild again because the attachment headers would disappear. I'll do this ASAP and reuse the existing attachment header code. Will split it out into another file for that, I think. Alternatively mhbuild could do the attachment header handling for send too, and instead send could protect #-beginning lines in any draft it gets. Does anyone think that's better? One more thing. Would anyone object to profile components like Attach-Header: X-MH-Attach Forward-Header: X-MH-Forward When I first started using the attachment handling stuff the fact that it was done with arguments to whatnow and send confused me. I think it might be good to keep that so that run-time overriding of the headers can be done (and perhaps this is an easier hook for frontends), but with this spreading to other commands now it might be nice to have a common, but overridable place to configure these. Cheers, - Joel _______________________________________________ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers