Gnus; Restore multi encoding support for NNTP

[LdBeth <andpuke@foxmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1953 bytes --]


I have this problem reported as bug #52792
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=52792

There used to be special handling to decode NNTP group names in
different coding systems, starts from Emacs 27 these are removed in
favor of working with UTF-8 internally. That works fine with emails or
RSS, but not so with NNTP servers that are trends to retain their old
setting, which results in some group names cannot be correctly
display in Group Buffer.

However, since this bug only affects people who are using Gnus with
NNTP servers that still using none UTF-8 complaint charset, I guess
it'll be better that I get hands on it.

The basic plan is to restore the option to decode group names based on
`gnus-group-name-charset-group-alist'. The reason having this custom
variable is because a server could use different incompatible charset
especially when group names are in different languages.  It seems this
variable is not been used in else where except for decode group name
been displayed in article buffer.

However, that would only resolve the display issue. Other changes are
needed to properly restore the decoded names to it's original coding
so requests to the NNTP server can be properly done.

The old Gnus code caches the original coding via the deleted
`gnus-agent-decoded-group-names' variable, the original string is
passed everywhere and converted to user's coding system for
display. To go with the original approach means reverting part of the
commit cb12a84f2c519a48dd87453c925e3bc36d9944db for NNTP related
functions.

A possible new approach, is to save the original coding system via the
charset string property, and go for UTF-8 internally. I'm not yet sure
if that could be lose during Gnus' internal processing.

The middle way is keep the mapping relation in an alist or hashtable,
and convert back to the original encoding for communicate the server.

Thoughts, comments, related information are appreciated.

--
LDB

[-- Attachment #2: OpenPGP Digital Signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]