heh. no, not too technical at all. my comment was more of an attempt at
a wry "huh, you say it simply works, and always has? tell me more!" :-)
Heh. I forget sometimes people haven't been staring at the relevant RFCs
all of the time, like I have as part of working on nmh. If you want to
read more, a good place to start is to Google "rfc 5322" (the latest
version of standard for the format of email). If you look at that and
RFC 2047 (the document that describes the header encoding scheme under
discussion) you can see what I'm talking about (specifically, check out
RFC 5322 and section 3.2.2, which describes exactly what an atom is).
yeah, "git blame" told me the same story last night, while i was diagnosing
my MM_CHARSET issue. i guess i just thought mh was mime-unaware in so
many aspects that i shouldn't expect that to work. it wouldn't have
mattered, though, since i only finally got the rest of my working
environment -- locales, terminal programs, editor configuration -- to
be fully utf8 aware during the past few months. yeah, so, i'm a
little slow.
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.
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.
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