> > 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 [email protected] http://lists.nongnu.org/mailman/listinfo/nmh-workers
