From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Kenichi Handa Newsgroups: gmane.emacs.devel Subject: Re: Need some help with Rmail/mbox Date: Wed, 24 Sep 2008 09:56:28 +0900 Message-ID: References: <87y71o4xw6.fsf@xemacs.org> <48D33A10.4040102@pajato.com> <871vzfi93y.fsf@xemacs.org> <03b276ff-e070-465e-9486-c02e4725a3e0@broken.deisui.org> <1bd9e4e5-9349-438b-92af-c2a6293491e7@broken.deisui.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Trace: ger.gmane.org 1222217828 31630 80.91.229.12 (24 Sep 2008 00:57:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 24 Sep 2008 00:57:08 +0000 (UTC) Cc: pmr@pajato.com, eliz@gnu.org, ueno@unixuser.org, stephen@xemacs.org, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 24 02:58:03 2008 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 1KiIhb-0004NN-C7 for ged-emacs-devel@m.gmane.org; Wed, 24 Sep 2008 02:58:00 +0200 Original-Received: from localhost ([127.0.0.1]:49060 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KiIgY-0006qH-TR for ged-emacs-devel@m.gmane.org; Tue, 23 Sep 2008 20:56:54 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KiIgT-0006qB-Va for emacs-devel@gnu.org; Tue, 23 Sep 2008 20:56:49 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KiIgQ-0006pz-P9 for emacs-devel@gnu.org; Tue, 23 Sep 2008 20:56:49 -0400 Original-Received: from [199.232.76.173] (port=46733 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KiIgQ-0006pw-JZ for emacs-devel@gnu.org; Tue, 23 Sep 2008 20:56:46 -0400 Original-Received: from mx1.aist.go.jp ([150.29.246.133]:61583) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KiIgM-0000AL-2p; Tue, 23 Sep 2008 20:56:42 -0400 Original-Received: from rqsmtp2.aist.go.jp (rqsmtp2.aist.go.jp [150.29.254.123]) by mx1.aist.go.jp with ESMTP id m8O0uUmP025595; Wed, 24 Sep 2008 09:56:30 +0900 (JST) env-from (handa@m17n.org) Original-Received: from smtp2.aist.go.jp by rqsmtp2.aist.go.jp with ESMTP id m8O0uUJX027592; Wed, 24 Sep 2008 09:56:30 +0900 (JST) env-from (handa@m17n.org) Original-Received: by smtp2.aist.go.jp with ESMTP id m8O0uTw7007073; Wed, 24 Sep 2008 09:56:29 +0900 (JST) env-from (handa@m17n.org) Original-Received: from handa by etlken.m17n.org with local (Exim 4.69) (envelope-from ) id 1KiIg8-0002gr-T1; Wed, 24 Sep 2008 09:56:28 +0900 In-reply-to: (message from Stefan Monnier on Mon, 22 Sep 2008 10:10:48 -0400) User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/23.0.60 (i686-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) X-detected-operating-system: by monty-python.gnu.org: Solaris 9 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:104084 Archived-At: In article , Stefan Monnier writes: > > (1) Do decode-coding-region while specifying a multibyte > > buffer as TARGET. > > (2) Insert the contents of unibyte buffer into a multibyte > > buffer, and then perform decode-coding-region in that > > multibyte buffer. > > (3) Get a unibyte string form a unibyte buffer, and then > > decode it while specifying a multibyte buffer as TARGET. > > (4) Deocde a unibyte buffer into a mulitbyte string, and > > then insert it into a multibyte buffer. > > (Please note that using decode-coding-region directly in a > > unibyte-buffer is not reliable because if a coding system > > has post-read-converion function, that funcion (usually) > > works only in a mutlibyte buffer.) > > The efficiency is (1) > (2) > (3) > (4). > I'd have expected 3 to be more efficient than 2 since it doesn't need to > use the variable width multibyte representation of binary data. > [ I'd even expect 3 to be about as efficient as 1. ] > Is this because of the need to copy the string contents to a temp buffer > in order to run any potential pre-read-conversion function? We don't have pre-read-conversion but post-read-conversion, and if the coding system doesn't have post-read-conversion, a temp buffer is not used. The reason why I think (2)>(3) is because of a cost of making a unibyte string. And handling multibyte representation of binary data within decoder/encoder (written in C) is trivial. --- Kenichi Handa handa@ni.aist.go.jp