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 -descr
iption="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've been doing that for years, with help from emacs
functions and key definitions. Even with that support, I
still made a copy-and-paste error last week. And not the
first time.
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?
While it may not be obvious :-), I want simple, as well.
And more foolproof. But I also want configurable. I know
that I would never use any of the command line options
above. Maybe I should just not bother with them.
The one thing I do want to be configurable is the build
directive. Again, it's not something that I'll change, so
it can go into my .mh_profile. But, what's the best way to
communicate it (currently it has three pieces) to
make_mime_composition_file_entry ()?
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.
Got it. It's easier given nmh's current state, as well.
David
_______________________________________________
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers