From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/63864 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.pretest.bugs,gmane.emacs.gnus.general Subject: Re: `.newsrc.eld' saves chinese group name in wrong coding Date: Sun, 22 Oct 2006 23:55:29 -0400 Message-ID: References: <87mz7tm2wn.fsf@furball.mit.edu> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1161575756 24615 80.91.229.2 (23 Oct 2006 03:55:56 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 23 Oct 2006 03:55:56 +0000 (UTC) Cc: emacs-pretest-bug@gnu.org, yamaoka@jpl.org, id.brep@gmail.com, ding@gnus.org Original-X-From: emacs-pretest-bug-bounces+gebp-emacs-pretest-bug=gmane.org@gnu.org Mon Oct 23 05:55:53 2006 Return-path: Envelope-to: gebp-emacs-pretest-bug@gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Gbqui-0001GQ-E6 for gebp-emacs-pretest-bug@gmane.org; Mon, 23 Oct 2006 05:55:48 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Gbqui-0002QI-2O for gebp-emacs-pretest-bug@gmane.org; Sun, 22 Oct 2006 23:55:48 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Gbqub-0002NY-7e for emacs-pretest-bug@gnu.org; Sun, 22 Oct 2006 23:55:41 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GbquZ-0002LF-1x for emacs-pretest-bug@gnu.org; Sun, 22 Oct 2006 23:55:40 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GbquY-0002L2-MM for emacs-pretest-bug@gnu.org; Sun, 22 Oct 2006 23:55:38 -0400 Original-Received: from [209.226.175.188] (helo=tomts25-srv.bellnexxia.net) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GbquV-0001hY-TK; Sun, 22 Oct 2006 23:55:36 -0400 Original-Received: from pastel.home ([70.55.81.188]) by tomts25-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP id <20061023035534.BBIB1747.tomts25-srv.bellnexxia.net@pastel.home>; Sun, 22 Oct 2006 23:55:34 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 7DC168284; Sun, 22 Oct 2006 23:55:29 -0400 (EDT) Original-To: Eli Zaretskii In-Reply-To: (Eli Zaretskii's message of "Sat\, 21 Oct 2006 11\:22\:40 +0200") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) X-BeenThere: emacs-pretest-bug@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for CVS Emacs." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-pretest-bug-bounces+gebp-emacs-pretest-bug=gmane.org@gnu.org Errors-To: emacs-pretest-bug-bounces+gebp-emacs-pretest-bug=gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.pretest.bugs:14740 gmane.emacs.gnus.general:63864 Archived-At: >> >> It could be, although it would make sense to manipulate group names in >> >> "encoded" form, in the sense of "not decoded". >> >> > It could ``make sense'', but it's IMO a bad idea, since, as we both >> > know, Emacs is not well suited to handling unibyte strings. >> >> Huh? Unibyte strings are perfectly well supported as far as I know. >> >> You have to be careful to remember which strings are unibyte and which are >> multibyte, so you don't decode multibyte strings or encode unibyte strings, >> and especially not implicitly (by inserting a unibyte string in a multibyte >> buffer or vice versa). So if you mean that it requires discipline, then >> I agree, but otherwise I don't know what you're referring to. > To me, the second paragraph is precisely the meaning of ``not well > suited'' and ``not perfectly supported''. What kind of ``well > supported'' is that if I as a programmer need to carry with each > string additional information, and make sure I know _exactly_ what > primitives are invoked by every function I call, to take care that I > don't inadvertently call something that deep inside assumes I passed a > multibyte string? > That way lies madness. Agreed, but note that this problem is as much on the unibyte side as it is on the multibyte side, so that seems to imply that you also thing that Emacs is not well suited to handling multibyte strings. This said, I agree that Emacs should help more. E.g. by signalling an error when trying to insert multibyte text into a unibyte buffer. Stefan