Re: [Nmh-workers] Understanding nmh (aka. What's the goal) [ really non-ASCII message bodies ]

[Jon Steinhart]

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