From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Need some help with Rmail/mbox Date: Sun, 21 Sep 2008 18:07:10 -0400 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 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1222034909 22819 80.91.229.12 (21 Sep 2008 22:08:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 21 Sep 2008 22:08:29 +0000 (UTC) Cc: pmr@pajato.com, stephen@xemacs.org, ueno@unixuser.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 22 00:09:26 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 1KhX7M-0003Wg-NH for ged-emacs-devel@m.gmane.org; Mon, 22 Sep 2008 00:09:24 +0200 Original-Received: from localhost ([127.0.0.1]:47040 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KhX6K-0007wi-WD for ged-emacs-devel@m.gmane.org; Sun, 21 Sep 2008 18:08:21 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KhX6G-0007wd-1d for emacs-devel@gnu.org; Sun, 21 Sep 2008 18:08:16 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KhX6E-0007wQ-Mc for emacs-devel@gnu.org; Sun, 21 Sep 2008 18:08:15 -0400 Original-Received: from [199.232.76.173] (port=36546 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KhX6E-0007wN-FE for emacs-devel@gnu.org; Sun, 21 Sep 2008 18:08:14 -0400 Original-Received: from ironport2-out.pppoe.ca ([206.248.154.182]:41591 helo=ironport2-out.teksavvy.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KhX6A-00047u-1g; Sun, 21 Sep 2008 18:08:10 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjkGACdi1kjO+KDT/2dsb2JhbACBXbJhgWaBBA X-IronPort-AV: E=Sophos;i="4.32,442,1217822400"; d="scan'208";a="27205810" Original-Received: from 206-248-160-211.dsl.teksavvy.com (HELO ceviche.home) ([206.248.160.211]) by ironport2-out.teksavvy.com with ESMTP; 21 Sep 2008 18:08:07 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id 7AD26B404C; Sun, 21 Sep 2008 18:07:10 -0400 (EDT) In-Reply-To: (Eli Zaretskii's message of "Sun, 21 Sep 2008 23:56:55 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. 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:104017 Archived-At: >> >> 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. Stefan