Still trying to understand this. Decided to finally look at the code instead of
relying on my fading memory. Sorry if some of my earlier memory-based comments
were off-base. Please let me know if my understanding of your proposed patch is
correct.
The existing code takes a non-ASCII message body and sends it as an attachment
of type application/octet-stream.
Your patch changes this behavior so that it is sent as type text/plain with the
appropriately chosen character set.
In order to do this, you test the message body for non-ASCII characters in
attach(). If you find any, you write an entry directly into the composition
file instead of calling make_mime_composition_file_entry().
This is changing existing behavior if I understand it correctly. This is fine
with me provided that users must explicitly enable the change using an option.
Now that I'm actually looking at the code, I would suggest an option
(choose a better name) of binary-body-content-type. You could change the
make_mime_composition_file_entry() line
content_type = binary ? "application/octet-stream" : "text/plain";
to replace the "application/octet-stream" with the option value, or the existing
value as a default if the option is not specified.
A user wanting this behavior would have a profile entry of
binary-body-content-type: text/plain
I think that this would be a simpler code change that would accomplish your
goal.
Jon
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
http://lists.nongnu.org/mailman/listinfo/nmh-workers