Hi Ken,
But my point stands. nmh should know from the context where the
email address appears what encoding the bytes use when trying to
parse it.
- mail/inbox/42 was written by us; it's our choice.
- mail/draft is the process's locale.
- /var/spool/$LOGNAME is in UTF-8.
Right, but ... reality rears it's ugly head.
The address parser is a bunch of layers down. And it's used for a lot
of things. For example, stuff from .mh_profile can end up being
parsed by it. We'd have to change the internal API to indicate where
an address is coming from and I think we'd have to change it almost
everywhere.
I quite agree the current code greatly hinders doing anything about
this.
And then, to get back to my original point ... if we see an 8-bit
character that is not valid in the current character set, what,
exactly, should we do about it?
Complain precisely, e.g. pathname, line number, column, encoding
expected, byte(s) seen. I'd expect an nmh user to want to understand
how the parts of their system work and where something has gone wrong
and a good error message will help diagnose problems rather than just
passing duff data on so it causes problems further away from the origin.
--
Cheers, Ralph.