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
_______________________________________________
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers