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 > [email protected] > https://lists.nongnu.org/mailman/listinfo/nmh-workers =--------------------- paul fox, [email protected] (arlington, ma, where it's 74.1 degrees) _______________________________________________ Nmh-workers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
