Re: [Nmh-workers] Editing MIMEd messages, etc.

[Joel Reicher]

> > > 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