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: Re: [PATCH] Gnus; Restore multi encoding support for NNTP Date: Mon, 03 Jan 2022 22:00:42 +0800 Message-ID: References: <87wnjqb62b.fsf@gnus.org> <87sfueb3y1.fsf@gnus.org> <87wnjm6tbs.fsf@gnus.org> <874k6o7okc.fsf@gnus.org> <87v8z13w54.fsf@gnus.org> Mime-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22336"; 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) Cc: Eric Abrahamsen , LdBeth , Emacs Devel To: Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Jan 03 15:02:57 2022 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 1n4NvL-0005ae-VM for ged-emacs-devel@m.gmane-mx.org; Mon, 03 Jan 2022 15:02:56 +0100 Original-Received: from localhost ([::1]:40850 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n4NvK-0006A6-Tm for ged-emacs-devel@m.gmane-mx.org; Mon, 03 Jan 2022 09:02:54 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:37348) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n4Ntd-0005O8-9Z for emacs-devel@gnu.org; Mon, 03 Jan 2022 09:01:09 -0500 Original-Received: from out162-62-58-216.mail.qq.com ([162.62.58.216]:55567) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n4NtU-00009Y-30 for emacs-devel@gnu.org; Mon, 03 Jan 2022 09:01:04 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=foxmail.com; s=s201512; t=1641218444; bh=YiscNcyXM/NtfbY23QjFFwWhGR5ocqfk6b6+9fxTUz8=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=tmCkOeyt8taD1FclC00X41p3qgSyeB+CTHo0bX9bEBjZPkVQDOomvNG5w+lHdQ/4j EEHeuwLkcsse6CGMXsLST8Nc5A7VG6p7zbQwnsm1x736Gli6PMkP5Fcp934D+vosaN ptarTAsEu39LWTpQXkkWjRa0PsCbg+I7v47qInVw= Original-Received: from Costume-Party.local ([39.189.27.124]) by newxmesmtplogicsvrszc6.qq.com (NewEsmtp) with SMTP id 2B2321B; Mon, 03 Jan 2022 22:00:43 +0800 X-QQ-mid: xmsmtpt1641218443tdc4pqpg9 X-QQ-XMAILINFO: McbooTuyDvAJ5mBY6p9+gu78uMyBc9VQgK+3Vdm6dWLXg2LR6R1Et9pxdtRA1B txUakQWVSK+y9TYyjnxqPxgBRdUrfqzcCxMfZTKnrqZ2ZMCsfe0r6KMOvd1bYYSCa8FH2rw7Pmjg BNCi0jN4PlsJSDbU+wUC9t3byoX232QRBiq9buCWRJPjVilZg41CAsbR0BEth3lD26jyP63lozy/ m1J0EjCoY9xbnxBwQZ/6u+2sGsFOLlRhdD2oCeZgv8y5GDu1PjVMijVvEzEqCkrYl/xg3Umi9FUp W+Z5tnA+tnfEcWU+aQY6rVmUHuHh29h3X2IA7lrXvojYEwiJuCF2BwTeLfaOYhhv3C5id/2JT6oF OzFJCl1h2ZfsWU7QImhXk9FBf1AEkQViIGeVGgWIPSvG2av7Ins9JfdTS9wCmtuqyc4Lg0j3ivkD CKWNHP8I7Uw+NhDuk+LVWbkh+W7p/iJeL3Ncj2btf/WMIe8M7gz0YKlHBsG16VE2u3xraY2d3h3/ gIWUh1d7g7NyxbamyxiuHkUov/8p/zMqDaI2bVEhcKakrosExKn6tfsh6kyj6QeSDBJeahScats0 KONdD21YIqum+Ge1BxafFzsM/04hw95t7FJqilZpycb7uD23OCKHQ3MIaqdqSW8ytPlt1RfuxAb/ /21offqWnOLZiAEGtTgtfOBfMiH/khraQJGxTJQTNMScfssF4t5QWCVsu3wB7fC/2+SRcmXyJRzQ sjc4eIEgt8c18yqfTV98/4DORhVKsRFt7YmClOzDw/0E5xiTo7zSuxsI2A6WZI872BZXb+SsN8ZS NJZH5NxqTK7Jc9qsZ6y0lELprvz3rQEciS935AnU Original-Received: by Costume-Party.local (Postfix, from userid 501) id 0210E203D73E36; Mon, 3 Jan 2022 22:00:42 +0800 (CST) X-OQ-MSGID: In-Reply-To: <87v8z13w54.fsf@gnus.org> 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=162.62.58.216; envelope-from=andpuke@foxmail.com; helo=out162-62-58-216.mail.qq.com X-Spam_score_int: 27 X-Spam_score: 2.7 X-Spam_bar: ++ X-Spam_report: (2.7 / 5.0 requ) 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, 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:284049 Archived-At: >>>>> In <87v8z13w54.fsf@gnus.org> >>>>> Lars Ingebrigtsen wrote: Lars> LdBeth writes: >> + (let ((pos (text-property-not-all 0 (length string) 'charset nil string))) >> + (if pos (encode-coding-string string (get-text-property pos 'charset string)) >> + string))) Lars> Like I said before, I'm not really very enthusiastic about Lars> stashing this data in the text properties -- it's quite likely Lars> that there are packages or functions of there that'll do various Lars> transforms on the group names, and the text properties may be Lars> lost. If this data has to be stored non-ephemerally, then Lars> storing it in the group parameter list, for instance, would be Lars> less brittle. Thanks for the suggestion, it seems possible to add the coding information group parameter list so the newsrc.eld file can still be saved with ASCII coding. However, before the group has been subscribed and added to `gnus-newsrc-hashtb', the charset information seems has no other place to be stored unless we add another bookkeeping facility. For the group names, they are store under the text property in group mode buffer and are retrieved via `(get-text-property (point) 'gnus-group)', it seems these are only been looked up and compared. Or maybe we could just prepend the charset information to the decoded group name. For example instead of `nntp+news.server.net:group.name' it becomes `nntp-gbk+news.server.net:group.name'. In that case the info is still attached with group name, and can certainly undergoes most of the transformations. >> @@ -472,7 +472,7 @@ gnus-request-compact-group >> (result >> (funcall (gnus-get-function gnus-command-method >> 'request-compact-group) >> - (gnus-group-real-name group) >> + (gnus-group-real-name (gnus-group-encoded-name group)) >> (nth 1 gnus-command-method) t))) >> result)) Lars> (etc.) And I'm not sure about giving the backends the encoded names -- Lars> that's a major change in behaviour, and has to end up causing problems Lars> somewhere (for instance, in nnimap which is encoded to utf-7, and would Lars> be double-encoded if there's a `charset' text property on the group Lars> name). In older version it's just a call to `string-as-unibyte'. And for nnimap, the `gnus-group-name-charset' function already avoids doing extra encoding. -- LDB