> > > 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? > > Well, mhbuild DOES do the attachment header handing for send. > > This is a bit tricky. I would say that if mhbuild is being run from send > then it should do what the current attachment code does which is to protect > the #s. But, if it is run using whatnow mime then it should not protect > them because it will make it useless. Possibly the thing to do is to have > yet another option to mhbuild that indicates whether or not to process > directives in the body. > > If you do this, then mhbuild may need to so some of the automatic filling > in of things like content-type that the current attachment code now does. > Again, probably an excuse to go option crazy on mhbuild.
Not quite what I meant. I certainly don't want to add another option to mhbuild. It's unnecessary. The two possibilities are as follows: 1) Put turn-header-into-mhbuild-directive code in a place that both send and mhbuild can use. End of story. 2) Put turn-header-into-mhbuild-directive code into *just* mhbuild, and have send preprocess #-beginning lines to protect them if it has detected any mhbuild-causing headers, i.e. it's about to hand the message over to mhbuild. It's purely an implementation question. > I have no objection to the new profile components, but would keep the old > options for compatibility. A question though - would you be able to > override these components on the command line? I feel that it's good to > be able to do so, which is why I went with the turn on/of option pairs > when I did the original code. Yes, I said I wanted these components to be overridable. To be honest I hadn't considered a -noattach option but perhaps it's needed for the semantics I'd intended. Cheers, - Joel _______________________________________________ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers