From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: LdBeth Newsgroups: gmane.emacs.devel Subject: Gnus; Restore multi encoding support for NNTP Date: Mon, 27 Dec 2021 17:42:42 +0800 Message-ID: Mime-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: multipart/signed; boundary="pgp-sign-Multipart_Mon_Dec_27_17:42:32_2021-1"; micalg=pgp-sha256; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16806"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.2 (x86_64-apple-darwin18.7.0) MULE/6.0 (HANACHIRUSATO) To: Emacs Devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Dec 27 10:43:59 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n1mXv-0004BC-6j for ged-emacs-devel@m.gmane-mx.org; Mon, 27 Dec 2021 10:43:59 +0100 Original-Received: from localhost ([::1]:59064 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n1mXt-0004go-5E for ged-emacs-devel@m.gmane-mx.org; Mon, 27 Dec 2021 04:43:57 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:40882) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n1mX7-00040d-Sg for emacs-devel@gnu.org; Mon, 27 Dec 2021 04:43:09 -0500 Original-Received: from out203-205-221-235.mail.qq.com ([203.205.221.235]:40304) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n1mWx-0006aa-PB for emacs-devel@gnu.org; Mon, 27 Dec 2021 04:43:06 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=foxmail.com; s=s201512; t=1640598167; bh=AVHaT4gb5GjvcqEUOKTTaDx7oo29brIAyqjPGXDdgQk=; h=Date:From:To:Subject; b=Jm14cHMRgariRhXmYRdoK+DfTeq4va1ePvrii0IjJ8ypu0O+Yyn/+dFKjTxsyivzz ipObrMG46eqAOQm9M7mFv/bLEQHt+Lu8LE6B7zu95xmpVexoICx59EVtL1DG7yvHxI 8woFGgPqaar1DJuDYxz4edspA8f+qnN2DMNl4QEc= Original-Received: from Costume-Party.local ([125.111.91.142]) by newxmesmtplogicsvrszc9.qq.com (NewEsmtp) with SMTP id AAE3941E; Mon, 27 Dec 2021 17:42:46 +0800 X-QQ-mid: xmsmtpt1640598166t7g9zrhpp X-QQ-XMAILINFO: MjQ00mYXMHtuikcRhdWD57Tb1rCEWS2+Iv7fbQx/P6oqQkGEEaJqJk7omtkBcz hHaeN2TY/zDoFZRFn7i9/zxpm2iXYKnS3EAMiaNACufctpUtZP8NBkQ4LulBTq3ESUeKa0iKso9c nGJGwrMfqLruWS1iVIkYvFhR74x6pYOT3Uf+ztgaY5n/bjLGkbaWwJmL3JT0YHi4RYo5+90Jmoqv hQkKUBDwyBVoyRkpOnup1sOPwrwfyojELyjNLxNTfB94rk9pczvXQv4EvrsjjY3nRHuBdynxs/w4 ySAcc9e1VDC2s9A/TBOVMSRlRDVHmD3Jf2QFcJ/iyMVpx81ug8LYTi3ImRSY2K62M3Y0zibZA6ax t3u8RfYZJHOTCRYY+GATsSLFOGo3eAgzqKq9ZsJAxTkxM+1NTRrUzH1mWhbQUL/+RJPT2lJMX09I JUlcR7Emxsv0kuc84MsrdOpxYLB5lyYIF/aRaJhI/EO6L9HI5NcYiyUvIFFe8KIALNsEB9Gq5zHN kYBuHDei/k9464BzOq5Dr0yyk+hTPJt8/IlQyNIUfLX5j/BYrEjHhNu8sNJoalYDulrZxWGgY7Nw LiaAmSiOEj8rpJgZCo6qQ74VqKuiNkr1sN5gSuVwjmiUxZCyHtZ0G0e0y/21iTDNEUT3JIc/+uMB tMNU52YJOmfScElZaewOS5CmfdyhtCdcixz5gR6ChOx847a/VtMzVaVdUKxGlwUwTR+9W33qRgUz MUiWkrZouyujJ1FcPIAjo7HAxXsVdIcPwPMaX+H+CMFFqj13ns+kbhwGhWaGN5GyFpQDqCK0EkcP SDpQKMDx6XUNktKUgseMpiDzjyWfqTjOnS0QkDRg Original-Received: by Costume-Party.local (Postfix, from userid 501) id C3861203D45014; Mon, 27 Dec 2021 17:42:42 +0800 (CST) X-OQ-MSGID: X-Face: %[!P\u/BKFRGn_9h9|yO"ho?C0ej^LmM}WMb-`Jfj8OsS^^AKmHYGlD@^|7SEA3UzOGPFbB"OFczY?'\JtJ\lR'@&Y5j; s8{$&|3D>^i.U4l2h?1qpD.+{[$~j]vBeHZf^|BGyL8{/`4 X-Attribution: ldb Received-SPF: pass client-ip=203.205.221.235; envelope-from=andpuke@foxmail.com; helo=out203-205-221-235.mail.qq.com X-Spam_score_int: 8 X-Spam_score: 0.8 X-Spam_bar: / X-Spam_report: (0.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HELO_DYNAMIC_IPADDR=1.951, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RDNS_DYNAMIC=0.982, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:283405 Archived-At: --pgp-sign-Multipart_Mon_Dec_27_17:42:32_2021-1 Content-Type: text/plain; charset=US-ASCII 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 --pgp-sign-Multipart_Mon_Dec_27_17:42:32_2021-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit Content-Description: OpenPGP Digital Signature -----BEGIN PGP SIGNATURE----- iHUEABEIAB0WIQQYUwRPFvNxyZSQqJDJKZHYLEzTIwUCYcmKiAAKCRDJKZHYLEzT IwpwAP9kmgU/EztsVE8lziDuLVua8ISvW95A3AJ2EhFCY3NmYQD/QqfPIZTt1Y91 KTI8xYvNHWXvTHEzX9VVwAP6HMYGJG8= =hikT -----END PGP SIGNATURE----- --pgp-sign-Multipart_Mon_Dec_27_17:42:32_2021-1--