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

[Jon Steinhart]

> How 'bout this?  Why not add another option similar to the -attach
> option that I added to whatnow and send?  Why not add a -forward
> option that would specify the name of another header that would be used
> for forwarding messages.  So, for example, if you had in your profile
> 
>       repl:           -forward X-MH-Forward
>       forw:           -forward X-MH-Forward
>       send:           -attach X-MH-Attachment -forward X-MH-Forward
>       whatnow:        -attach X-MH-Attachment
> 
> then if you were reading message inbox/10 and did a repl -mime it would
> add the header
> 
>       X-MH-Forward:           inbox/10

I think it might be nicer to mimic the syntax of the #forw directive
here, i.e. be able to say

X-MH-Forward: +inbox 10 15 21

There are a couple of reasons for this. Firstly, it allows for grouping
of forwarded message into digests, which is exactly what the #forw
directive allows. Secondly, it might be nice to permit the full power
of message ranges and sequences to be used.

As far as I can tell it does not make the implementation any more difficult,
since mhbuild still does all the work. I also think it is not any more
difficult to read, so it satisfies the aim of keeping these headers
intelligible. I think it's a little easier to read, in fact.

This seems fine to me.

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

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.

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.

Jon