[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Need some help with Rmail/mbox

From: Kenichi Handa
Subject: Re: Need some help with Rmail/mbox
Date: Wed, 24 Sep 2008 09:56:28 +0900
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)

In article <address@hidden>, Stefan Monnier <address@hidden> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]