From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/65671 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel,gmane.emacs.gnus.general Subject: Re: [Unicode-2] `read' always returns multibyte symbol Date: Wed, 14 Nov 2007 22:39:35 -0500 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1195097998 3763 80.91.229.12 (15 Nov 2007 03:39:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 15 Nov 2007 03:39:58 +0000 (UTC) Cc: Kenichi Handa , ding@gnus.org, emacs-devel@gnu.org To: Katsumi Yamaoka Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Nov 15 04:40:03 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1IsVaB-0006UW-P9 for ged-emacs-devel@m.gmane.org; Thu, 15 Nov 2007 04:40:00 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IsVZz-0000qO-7O for ged-emacs-devel@m.gmane.org; Wed, 14 Nov 2007 22:39:47 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IsVZu-0000px-Qa for emacs-devel@gnu.org; Wed, 14 Nov 2007 22:39:42 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IsVZp-0000p2-Sb for emacs-devel@gnu.org; Wed, 14 Nov 2007 22:39:41 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IsVZp-0000op-9q for emacs-devel@gnu.org; Wed, 14 Nov 2007 22:39:37 -0500 Original-Received: from tomts43.bellnexxia.net ([209.226.175.110] helo=tomts43-srv.bellnexxia.net) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IsVZo-00020n-Hg for emacs-devel@gnu.org; Wed, 14 Nov 2007 22:39:36 -0500 Original-Received: from ceviche.home ([70.53.194.136]) by tomts43-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP id <20071115033935.UJMN26794.tomts43-srv.bellnexxia.net@ceviche.home> for ; Wed, 14 Nov 2007 22:39:35 -0500 Original-Received: by ceviche.home (Postfix, from userid 20848) id 41EDCB4128; Wed, 14 Nov 2007 22:39:34 -0500 (EST) In-Reply-To: (Katsumi Yamaoka's message of "Thu, 15 Nov 2007 12:01:04 +0900") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.50 (gnu/linux) X-detected-kernel: by monty-python.gnu.org: Solaris 8 (1) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:83241 gmane.emacs.gnus.general:65671 Archived-At: > I think it's better, too. However, there might be a code that > copies data from nntp-server-buffer to a multibyte buffer. I'm > not capable to check all the Gnus code. I understand the desire to avoid changing code, but I think in the long run it'll pay off. >>> (IIUC, copying data from a multibyte buffer to a unibyte buffer >>> causes no problem). >> I'm not sure I understand: copying data from a multibyte buffer to >> a unibyte buffer is exactly the case that can cause problems. > I agree that's generally true. But in Gnus' case, data in a > multibyte work buffer are the multibyte version of binary data. > I don't know proper words to explain it, sorry. In other words, > they are the one which `string-to-multibyte' converted binary > data to. For example: > (with-temp-buffer > (set-buffer-multibyte t) > (insert (string-to-multibyte (encode-coding-string "=E6=97=A5=E6=9C=AC= =E8=AA=9E" 'utf-8))) > (let ((buffer (current-buffer))) > (with-temp-buffer > (set-buffer-multibyte nil) > (insert-buffer-substring buffer) > (decode-coding-string (buffer-string) 'utf-8)))) > =3D> "=E6=97=A5=E6=9C=AC=E8=AA=9E" > I'm not sure it works with any data, though. I'm not sure what you're saying. But IIUC the source buffer in your example would be nntp-server-buffer, in which case turning it into unibyte will not introduce any problem. On the contrary, it'll make it more obviously correct. Stefan