Re: [Nmh-workers] Should attachment header handling be in send?

[Joel Reicher]

> Jon Steinhart wrote:
> 
> > > The attach command is convenient though. Perhaps if the -attach option
> > > is not set in .mh_profile, attach could add an mhbuild directive to the
> > > body.
> > 
> > I'm not sure what you mean by this.  Are you suggesting that if some option
> > is not set in the profile, then the whatnow attach command run mhbuild?
> > Wouldn't that be the same as running the whatnow mime command?
> 
> Currently, the attach command defaults to printing:
>   "whatnow: can't attach because no header field name was given."
> If a header field name is given it adds the filename to the header. What
> I'm suggesting is that the default is to construct an mhbuild directive
> - something like `#text/plain; name="foo" <>[] ~/foo' and stick it on
> the end of the body of the message draft.

That's a little misleading. With the attach command as it currently
stands the attachment is guaranteed to be done, or at least not
fail silently. With what you are wanting, however, the attachment will not
be done until the user explicitly runs the draft through mhbuild, or has
automimeproc set.

One of the nice things about Jon's scheme is that it effectively saves
state in the draft with the presence of a new header, i.e. the state of
there being pending attachments, and this header indicates to send that
the draft needs extra processing.

Cheers,

        - Joel