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