nmh-workers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] Second release candidate for nmh 1.6 now available


From: David Levine
Subject: Re: [Nmh-workers] Second release candidate for nmh 1.6 now available
Date: Sun, 04 May 2014 21:30:38 -0400

> >That would help.  But I think that the whole business should
> >be reviewed and possibly redesigned.  As in, provide an sbr
> >function to say whether or not two charset names match.
> >Callers that just need that would no longer have to be
> >concerned with memory management.
> 
> I just realized something ... we're using norm_charmap() wrong.
> 
> The purpose of norm_charmap() is to convert a _locale_ character set
> (what is returned by nl_langinfo(CODESET)) into a standard MIME
> character set.  AFACT, norm_charmap() should almost never be used by
> nmh applications; they should be using get_charset() if they need
> the local character set.  If it's something in email, we can use it
> directly and it should not be run through norm_charmap().

I don't follow.  What if the email says that it's something
that norm_charmap() would convert to US-ASCII or one of the
others that it modifies.  How do we know if that matches
the user's locale character set?

And with mhfixmsg, the user's locale doesn't enter in at
all.  The user can translate the message from whatever
it is to whatever the user wants (assuming that iconv
supports the translation).  mhfixmsg uses norm_charmap()
when deciding whether that translation isn't necessary.
I'd be OK with removing the norm_charmap() here, on the
assumption that users (and emails) will say "US-ASCII"
and not one of its aliases.

David



reply via email to

[Prev in Thread] Current Thread [Next in Thread]