GNU bug report logs - #52792
27.2; please don't hardcode utf-8 when fetching group list

Previous Next

To reply to this bug, email your comments to 52792 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: LdBeth <andpuke <at> foxmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.2; please don't hardcode utf-8 when fetching group list
Date: Sun, 26 Dec 2021 00:19:03 +0800

The problematic code is located at gnus-srvr.el,
`gnus-browse-foreign-server' in commit
cb12a84f2c519a48dd87453c925e3bc36d9944db, that hard codes
`utf-8-emacs' for group lists. That would cause problems for NNTP
servers that are still not using utf-8, which is common among some
Chinese servers that widely uses gbk coding. It would render group
subscription unusable when `gnus-group-name-charset-group-alist' has
been setup to translate the group names, because Gnus would think
the translated group names different from the wrongly decoded group name
fetched from the server.

I propose for reverting the removal of group name encoding, although I
didn't fully understand the reason for that commit. Or at least,
consider add a method to set the encoding for particular server, to
work around this problem.

-- 
LDB

Message #8 received at 52792 <at> debbugs.gnu.org (full text, mbox):

From: LdBeth <andpuke <at> foxmail.com>
To: 52792 <at> debbugs.gnu.org
Subject: Re: 27.2; please don't hardcode utf-8 when fetching group list
Date: Sun, 26 Dec 2021 10:00:42 +0800

[Message part 1 (text/plain, inline)]

This patch that reverts only related changes (and does nothing else)
in cb12a84f2c519a48dd87453c925e3bc36d9944db should make Gnus works
again for none utf-8 NNTP servers.

[revert.diff (text/plain, attachment)]

Message #11 received at 52792 <at> debbugs.gnu.org (full text, mbox):

From: LdBeth <andpuke <at> foxmail.com>
To: 52792 <at> debbugs.gnu.org
Subject: Re: 27.2; please don't hardcode utf-8 when fetching group list
Date: Sun, 26 Dec 2021 10:25:40 +0800

>>>>> In <tencent_03F53C61E4EB9C58CDFE99B951775739820A <at> qq.com> 
>>>>>	LdBeth <andpuke <at> foxmail.com> wrote:
ldb> [1  <text/plain; US-ASCII (7bit)>]

ldb> This patch that reverts only related changes (and does nothing
ldb> else) in cb12a84f2c519a48dd87453c925e3bc36d9944db should make
ldb> Gnus works again for none utf-8 NNTP servers.

ldb> [2 revert.diff <text/plain; US-ASCII (7bit)>]

Unfortunately that only resolves the display problem, to enable
correct subscription on none UTF-8 nntp server would require undone
other changes in cb12a84f2c519a48dd87453c925e3bc36d9944db.

-- 
LDB

Message #14 received at 52792 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: LdBeth <andpuke <at> foxmail.com>
Cc: 52792 <at> debbugs.gnu.org
Subject: Re: bug#52792: 27.2;
 please don't hardcode utf-8 when fetching group list
Date: Sun, 26 Dec 2021 09:00:54 +0200

> Date: Sun, 26 Dec 2021 10:00:42 +0800
> From: LdBeth <andpuke <at> foxmail.com>
> 
> This patch that reverts only related changes (and does nothing else)
> in cb12a84f2c519a48dd87453c925e3bc36d9944db should make Gnus works
> again for none utf-8 NNTP servers.

Thanks, but this is not the right way to solve such problems, IMO.  We
should either make the coding-system be customizable as a simple
value, or (better) have a more complex data structure that allows to
specify the encoding for each NNTP server (or for servers matching
some regexp), with UTF-8 being the default.

Also, AFAICT, Gnus currently uses more than a single variable to hold
the coding-system it uses for decoding stuff in different situations,
so some changes will probably be needed to use a single customizable
value everywhere.

Message #17 received at 52792 <at> debbugs.gnu.org (full text, mbox):

From: LdBeth <andpuke <at> foxmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: LdBeth <andpuke <at> foxmail.com>, 52792 <at> debbugs.gnu.org
Subject: Re: bug#52792: 27.2;
 please don't hardcode utf-8 when fetching group list
Date: Sun, 26 Dec 2021 17:49:56 +0800

>>>>> In <83tuevq28p.fsf <at> gnu.org> 
>>>>>	Eli Zaretskii <eliz <at> gnu.org> wrote:

> Thanks, but this is not the right way to solve such problems, IMO.  We
> should either make the coding-system be customizable as a simple
> value, or (better) have a more complex data structure that allows to
> specify the encoding for each NNTP server (or for servers matching
> some regexp), with UTF-8 being the default.

Right, it would be more desirable to use UTF-8 internally, rather than
doing ad-hoc encoding translation everywhere.

> Also, AFAICT, Gnus currently uses more than a single variable to hold
> the coding-system it uses for decoding stuff in different situations,
> so some changes will probably be needed to use a single customizable
> value everywhere.

Currently the encode/decode functions in message.el works fine for
GBK, this bug would not affect people who are only using Gnus for
IMAP/Maildir.  It would still better leaving these two systems (News
and Messages) separated. Today most email services are already
switched to UTF-8. It's only that many NNTP servers are still using
the old encoding for legacy reasons.

-- 
LDB

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.