nmh-workers
[Top] [All Lists]

Re: [Nmh-workers] question about encoded recipient names

2012-06-10 11:07:46

ken wrote:
I'm a bit late to the UTF-8 party myself, so I understand where you're
coming from.  But there is one thing that puzzles me; if you don't set
MM_CHARSET, everything should have worked.  You said that you have
wrappers that set MM_CHARSET for some programs ... but for the programs
that you didn't set MM_CHARSET for, why didn't it work?  This is all
assuming your locale setting were properly propagated to "scan" and
friends.

okay, this is sort-of embarrassing, and i was hoping no one would
wonder about that. :-)  a number of years ago, when i was debugging my
wrappers, i wanted to be sure that all was working properly -- it wasn't
not always obvious what was being invoked when, when i set "showproc",
or "editor" to a wrapper script (my editor wrapper invokes showproc in
the case of repl and forw, to get a good copy of the body in place). 
so to make sure my MM_CHARSET assignments were being effective, in my
.bash_profile i had set MM_CHARSET="foobar".  literally.  and that's
been there ever since.  so my (unwrapped) scan invocation never stood
a chance.  :-)

as for deprecating MM_CHARSET entirely...  i suppose that's okay.  but
for arguments sake, say i had a non-utf8-aware editor, or pager, or
terminal program -- it's a lot easier for me to invoke an mh program
with MM_CHARSET=us-ascii than it is to figure out which locale setting
to undo, and what to set it to.  i suppose that's not really an excuse
for maintaining an obsolete mechanism, but it seems like simply
documenting MM_CHARSET as being intended as a fallback mechanism which
might be useful in unusual circumstances would be less work than
removing it.


i noticed that the provided mhl.* and scan.* and repl*comps aren't
uniform in their use of "decode" for address fields.  for instance, To
and Cc headers don't ever use it, and From and Reply-to are
inconsistent as well.  is there any reason not to simply use it
everywhere?

There are some cautions here.  Right now mhbuild cannot encode RFC 2047
headers, so if we're just displaying the decoded headers it's fine.

ah.  thanks for the warning on that.

paul

But for things like replcomps we should probably NOT use it right now,
because we'd end up with addresses and Subject lines that would have
non-ASCII characters in them that we can't encode properly.  Right now
since nmh doesn't decode them in these cases.

My medium-term plan is to have nmh run mhbuild for you always so we
don't generate messages with non-ASCII characters without the proper
MIME headers.  Part of that plan is to have mhbuild encode those
headers properly (in case you're curious, when I sent out a subject
line last month with a Euro symbol in it I encoded it by hand).

--Ken

_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

=---------------------
 paul fox, pgf(_at_)foxharp(_dot_)boston(_dot_)ma(_dot_)us (arlington, ma, 
where it's 74.1 degrees)

_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

<Prev in Thread] Current Thread [Next in Thread>