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

[Paul Fox]

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
 > address@hidden
 > https://lists.nongnu.org/mailman/listinfo/nmh-workers

=---------------------
 paul fox, address@hidden (arlington, ma, where it's 74.1 degrees)