From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Need some help with Rmail/mbox Date: Mon, 22 Sep 2008 06:07:34 +0300 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> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1222052883 25311 80.91.229.12 (22 Sep 2008 03:08:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 22 Sep 2008 03:08:03 +0000 (UTC) Cc: pmr@pajato.com, stephen@xemacs.org, ueno@unixuser.org, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 22 05:09:00 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 1KhbnG-0002J1-N4 for ged-emacs-devel@m.gmane.org; Mon, 22 Sep 2008 05:08:58 +0200 Original-Received: from localhost ([127.0.0.1]:42164 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KhbmF-0007fY-5G for ged-emacs-devel@m.gmane.org; Sun, 21 Sep 2008 23:07:55 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Khbm3-0007cY-Mi for emacs-devel@gnu.org; Sun, 21 Sep 2008 23:07:43 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Khbm3-0007cI-3K for emacs-devel@gnu.org; Sun, 21 Sep 2008 23:07:43 -0400 Original-Received: from [199.232.76.173] (port=33580 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Khbm2-0007cD-UL for emacs-devel@gnu.org; Sun, 21 Sep 2008 23:07:42 -0400 Original-Received: from mtaout2.012.net.il ([84.95.2.4]:31576) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Khbm2-0005tW-LH for emacs-devel@gnu.org; Sun, 21 Sep 2008 23:07:42 -0400 Original-Received: from HOME-C4E4A596F7 ([77.127.116.246]) by i_mtaout2.012.net.il (HyperSendmail v2004.12) with ESMTPA id <0K7K00IOZU2CZKR1@i_mtaout2.012.net.il> for emacs-devel@gnu.org; Mon, 22 Sep 2008 06:08:41 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by monty-python.gnu.org: Solaris 9.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:104021 Archived-At: > From: Stefan Monnier > Cc: ueno@unixuser.org, pmr@pajato.com, stephen@xemacs.org, emacs-devel@gnu.org > Date: Sun, 21 Sep 2008 18:07:10 -0400 > > >> >> The only reliable way to do decoding in buffers is by using > >> >> the `destination' argument to decode-coding-region so that you can > >> >> decode from a unibyte buffer into a multibyte buffer. > >> > Why is that the only reliable method, and what do you suggest as the > >> > value of `destination' argument for it to DTRT? > >> As I said in my message: use the dest arg so as to "decode from > >> a unibyte buffer into a multibyte buffer", so `destination' should be > >> ... a multibyte buffer. > > And the source a unibyte one? > > Yes, of course. > > >> As for why it's the only reliable method, it's because: > >> >> Dealing with "bytes in a multibyte buffer" or with "non-ascii chars in > >> >> a unibyte buffer" (as is necessarily the case either as source or as > >> >> destination if you do the decoding in-place) is just too delicate in my > >> >> experience (and of course, it's also somewhat inefficient). > >> I'm not sure which part of the above paragraph is unclear. > > The fact that other methods are not 100% reliable does not yet mean > > that this one is. I thought you had a more specific explanation why > > this method is reliable. > > No, I don't have such an explanation, except that the most natural input > for decoding is a unibyte (string|buffer) and the most natural output is > a multibyte (string|buffer). I'd expect that to be pretty obvious. That would mean Rmail/mbox will need to use another unibyte scratch buffer for decoding MIME-encoded text: first qp- or b64-decode it into another unibyte buffer, then decode-coding-region from there to the (multibyte) display buffer.