Nice. Attach already takes the filename. Options would need to
include mime-type, name, mode, description, and Content-ID. Anything
else? If there's too much, it would get unwieldy.
Any suggestion on how to associate the option values with the build
directive? printf style?
whatnow: -attach X-MH-Attachment='#%T; name="%N" <%C>[%D; %M] %F'
whatnow? attach -mime-type=application/wierd -name=foo -mode=0x640
-description="my app" -contentid="" /tmp/foo
If any value in the build directive isn't specified, it
would be determined automatically (using mhshow-suffix for
the mime-type as it is now, and getting the name from the
filename, and so on).
While that example has a lot of typing, its purpose is to
show all the options. I expect to rarely specify options,
given a suitable build directive, such as '#%T; name="%N"
<>[] %F', with the mime-type and name usually determined
automatically. I don't see a need to bother with mode or
description, and don't want contentid.
It might be possible to add support for Content-Disposition
here.
Um, gimme a break here. Why not just use mhbuild mime-composition files?
I added the attachment handling code so that non-geeks could send attachments.
This is heading in the opposite direction. How often are these cryptic
arguments really going to be used? How many other mailers care about this
sort of stuff? How many mail programs even look at this stuff?
If you decide to make these additions, keep in mind that they have to be done
in the send code, not in the whatnow code. This is because the design of the
attachment code was such that it would work independent of the user interface.
In particular, I know people who have hacked mh-e to add attachment headers.
Jon
_______________________________________________
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers