Oliver wrote:
David Levine wrote:
The option to suppress Content-ID: could be added to either
mhbuild or send. mhbuild seems like the right place,
because that's where the MIME message is created. And it's
trivial to do there.
I would prefer if the option could actually be added to the attach
whatnow command.
Instead of the X-MH-Attachment header containing simply the filename, it
could contain the full mhbuild directive. attach could then take options
for explicitly specifying the filename, description, mime-type etc. This
would also mean that it is possible to see what mime-type has been
chosen before running send.
I must admit that one of the things I've never liked about
X-MH-Attachment is that it does stuff like run `file' to build a
description and provides x-unix-mode. With a few profile entries that
could all be made configurable.
With regard to the new thread, I think it is basically right that
attachment header handling is done automatically when send is run. I
would however prefer if running the mime command (i.e. mhbuild) did the
job of attaching the files. This would mean that the actual work would
need to be done by mhbuild.
It's a minor point but another change I would make to the attachment
stuff is to make the -attach option to send and whatnow a single
standard profile entry.
Oliver
I'm not sure that I'd add an option to the whatnow attach command for this.
This seems like a personal preference set once and forget it kind of thing.
Also, I guess that it fails the geek test for me. It could be there but
nobody other than a geek would know what it was for. Doesn't seem like a
great ui choice to me.
I feel the same way about having the attachment header containing full
mhbuild directives. Not sure what you get from that; if you want to
do mhbuild directives, do 'em in the body, it still works. The whole idea
of the attachment stuff that I did was to make something that my partner,
a non-geek, could use. Maybe I'm reading too much into this thread, but
it seems like the direction is to further geekify nmh rather than making
it usable.
Adding options that make the attachment stuff more configurable is fine
by me. I guess the question that occurs is, does it really matter?
As far as mhbuild understanding attachment headers, that's a bit of a change
but could be done. By the way, mhbuild IS doing the work here
You could make the -attach option a single profile entry if you wanted to.
Not sure that it's worth breaking existing profiles at this point. While
it might have been misguided on my part, one of the reasons that I made
everything separate was to permit it to work easily with other user interfaces
than whatnow, for example mh-e.
Nice to see so much interest in this all of a sudden.
Jon
_______________________________________________
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers