Ralph Corderoy writes:
Well, let me make this alternate proposal:
- "attach" adds Nmh-Attachment headers as per usual. Maybe we'll add
something like: "attaching foo.pdf to message as application/pdf" so
the user can see what MIME type is being used (really, that's all I
- You can add or not add mhbuild directives to the message if you
- If you add mhbuild directives, you can run "mime" (also, you can run
"mime" even if you don't). mhbuild will be in charge of processing
Nmh-Attachment headers. If there are mhbuild directives, they get
added per usual; any content specified by Nmh-Attachment headers gets
appended to the message after all other content. This is a
significant change to the _implementation_, but it feels like where
that functionality should belong.
- If you try to "attach" after a "mime", you get an error.
- send runs "mhbuild -auto -nodirectives". "-auto" means, "don't
error out if there's a MIME-Version header, just don't process the
draft". "-nodirectives" means "don't process directives". But ...
Nmh-Attachment headers are still processed.
How does that look? More code rework, but it feels better. Also,
with this I think it actually accomplishes what you want (attach +
Looks good. I can't think of any problems at the moment.
Always one with the unpopular opinion, this doesn't do it for me.
This does not address a significant enough problem to justify the amount
of work and change to the code base for me. Of course, I'm not doing
the work here.
In my mind, the question is whether work is going to go into maintaining
a cryptic ui that few people use, or whether it's going to go into making
a good ui. I favor the latter.
So my opinion is to live with it for now. If you're happy with attach,
then use it. If you want to use mhbuild, go ahead. Just don't use both.
Save your energy for a coding effort with a greater value proposition.
Nmh-workers mailing list