[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Jon Steinhart
Subject: Re: [Nmh-workers] Understanding nmh (aka. What's the goal) [ really non-ASCII message bodies ]
Date: Tue, 07 Dec 2010 12:33:54 -0800

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

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 


reply via email to

[Prev in Thread] Current Thread [Next in Thread]