Re: Gnus; Restore multi encoding support for NNTP

[LdBeth]

Eric> The moral intent of the changes in
Eric> cb12a84f2c519a48dd87453c925e3bc36d9944db was to move the site of
Eric> group name decoding from just-in-time conversion before display
Eric> to the user, to conversion over-the-wire when talking to the
Eric> server. Meaning that group name strings should be decoded as
Eric> they arrive from the server, and encoded before they're sent to
Eric> the server. Locally (including in file names for agent/cache
Eric> files) they should always be utf-8-emacs.

Thanks for the explaination. Then I'll not go for the direction of
adding back the just-in-time conversion.

Eric> Gnus does not handle this situation correctly, and I can't imagine it
Eric> ever did.

Lars> I think it did, since we just kept the unencoded data in the newsrc
Lars> alist, and then decoded before displaying.  So you could have any number
Lars> of groups with names that decoded to the same displayed string.

Gnus used to store the raw byte strings so yes that was feasible.

Eric> How does this per-group encoding information arrive from the
Eric> server?

We never get encoding information directly from the server. Sometimes
the group names contain the coding system used in ASCII, most of the
time we just knowing that most NNTP servers hosting in the same
country or region uses the same coding system so we can match by the
top level domain names, that's why
`gnus-group-name-charset-group-alist' is been used. The last resort is
by guessing: there's a `find-coding-systems-string' function from
mule.el that works very well, other news clients might use their own
guessing utils.

-- 
LDB