From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/63878 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: Tue, 24 Oct 2006 14:03:50 -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 1161713077 8362 80.91.229.2 (24 Oct 2006 18:04:37 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 24 Oct 2006 18:04:37 +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 Tue Oct 24 20:04:31 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 1GcQdJ-0001gh-JN for gebp-emacs-pretest-bug@gmane.org; Tue, 24 Oct 2006 20:04:15 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GcQdJ-0007Je-7R for gebp-emacs-pretest-bug@gmane.org; Tue, 24 Oct 2006 14:04:13 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GcQdE-0007JU-5F for emacs-pretest-bug@gnu.org; Tue, 24 Oct 2006 14:04:08 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GcQd9-0007Hs-7j for emacs-pretest-bug@gnu.org; Tue, 24 Oct 2006 14:04:07 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GcQd8-0007HW-Ui for emacs-pretest-bug@gnu.org; Tue, 24 Oct 2006 14:04:03 -0400 Original-Received: from [132.204.24.67] (helo=mercure.iro.umontreal.ca) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GcQd4-00044l-FZ; Tue, 24 Oct 2006 14:03:58 -0400 Original-Received: from hidalgo.iro.umontreal.ca (hidalgo.iro.umontreal.ca [132.204.27.50]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id B260B2CF0DB; Tue, 24 Oct 2006 14:03:57 -0400 (EDT) Original-Received: from faina.iro.umontreal.ca (faina.iro.umontreal.ca [132.204.26.177]) by hidalgo.iro.umontreal.ca (Postfix) with ESMTP id 996F73FE0; Tue, 24 Oct 2006 14:03:50 -0400 (EDT) Original-Received: by faina.iro.umontreal.ca (Postfix, from userid 20848) id 7EE446CAC0; Tue, 24 Oct 2006 14:03:50 -0400 (EDT) Original-To: Eli Zaretskii In-Reply-To: (Eli Zaretskii's message of "Tue\, 24 Oct 2006 13\:27\:59 -0400") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) X-DIRO-MailScanner-Information: Please contact the ISP for more information X-DIRO-MailScanner: Found to be clean X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-2.82, requis 5, autolearn=not spam, ALL_TRUSTED -2.82) X-DIRO-MailScanner-From: monnier@iro.umontreal.ca 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:14772 gmane.emacs.gnus.general:63878 Archived-At: >> I'm not quite sure what is a "unibyte session" > A.k.a. "emacs --unibyte". I know that, but I'm not quite sure what it entails. This discussion is within the scope of code such as Gnus's, i.e. code which should work either way. >> but I think "stay 100% in >> unibyte" is fairly clear: only use unibyte buffers and strings in the >> relevant code (while other unrelated buffers and strings may be multibyte). > I think it's practically impossible to use only unibyte buffers for > any serious work, and therefore I don't consider this a feasible > solution. The operative term there is "in the relevant code". E.g. Gnus could easily (as opposed to "practically impossible") use unibyte for all its buffers and strings. It's also very common (and often necessary) to use unibyte buffers and strings to interact with underlying processes or network connections. Typically because the data passed back&forth may use mixes of various encodings. > If one uses the default multibyte session, using unibyte strings is > prone to subtle problems as described in this thread. But those problems are not specific to unibyte, but to the mix of unibyte and multibyte. In most packages such as Gnus it's just as hard/impossible to use only multibyte as it is to use only unibyte. Stefan