[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] Gnus; Restore multi encoding support for NNTP
From: |
LdBeth |
Subject: |
Re: [PATCH] Gnus; Restore multi encoding support for NNTP |
Date: |
Sat, 01 Jan 2022 17:26:00 +0800 |
User-agent: |
Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (Gojō) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.2 (x86_64-apple-darwin18.7.0) MULE/6.0 (HANACHIRUSATO) |
>>>>> In <83mtkfg7g1.fsf@gnu.org>
>>>>> Eli Zaretskii <eliz@gnu.org> wrote:
>> Eli> If by "using UTF-8 internally" you mean the internal representation of
>> Eli> buffer text and strings, then encoding is still needed for correct
>> Eli> handling of codepoints outside of Unicode.
>>
>> Gnus already uses `utf-8-emacs' coding to save the newsrc.eld file for
>> a while. According to the Elisp manual, that is the coding system
>> that can handle the internal codepoints used by Emacs.
Eli> You are saying that encoding by utf-8-emacs is a no-op? AFAIR, that's
Eli> not true.
I mean, there should be no problem `prin1' any emacs strings to a file
saved using utf-8-emacs coding, and correctly `read' them back given
the file has `-*- coding: utf-8-emacs -*-` header line.
Encoding by utf-8-emacs was used under the assumption that Gnus from a
much older version of Emacs can safely read the file. By treating
everything as UTF-8, Gnus has already broke the compatibility with
older versions (.newsrc.eld contains wrongly encoded characters cannot
work with older version that can do the correct encode/decode of none
UTF-8 group names), so I think there has no point to continue restrict
the charset of .newsrc.eld to be ASCII readable.
And so this patch can take the advantages of both the UTF-8 internal
string encoding without the redundancy of book keeping an extra
translation table, which probably can not be as good as the approach
taken by this patch.
--
LDB