From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Stefan Monnier" Newsgroups: gmane.emacs.devel Subject: Re: Different (buffer-file-)coding-systems for different regions of one buffer? (for Rmail MIME) Date: Wed, 21 May 2003 18:29:15 -0400 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <200305212229.h4LMTFKo001277@rum.cs.yale.edu> References: <200305211953.h4LJr9Iq000699@rum.cs.yale.edu> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: main.gmane.org 1053561758 23734 80.91.224.249 (22 May 2003 00:02:38 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 22 May 2003 00:02:38 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Thu May 22 02:02:36 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19IdWw-00068U-00 for ; Thu, 22 May 2003 02:01:58 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 19Idhx-0005Mr-00 for ; Thu, 22 May 2003 02:13:21 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.20) id 19IdPz-0000lp-Iq for emacs-devel@quimby.gnus.org; Wed, 21 May 2003 19:54:47 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19IdPR-0000kn-Hk for emacs-devel@gnu.org; Wed, 21 May 2003 19:54:13 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19Icbr-0001iU-2E for emacs-devel@gnu.org; Wed, 21 May 2003 19:03:31 -0400 Original-Received: from rum.cs.yale.edu ([128.36.229.169]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19Ic5E-0004RD-An for emacs-devel@gnu.org; Wed, 21 May 2003 18:29:16 -0400 Original-Received: from rum.cs.yale.edu (localhost [127.0.0.1]) by rum.cs.yale.edu (8.12.8/8.12.8) with ESMTP id h4LMTFx6001279; Wed, 21 May 2003 18:29:15 -0400 Original-Received: (from monnier@localhost) by rum.cs.yale.edu (8.12.8/8.12.8/Submit) id h4LMTFKo001277; Wed, 21 May 2003 18:29:15 -0400 X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 Original-To: stktrc X-MIME-Autoconverted: from 8bit to quoted-printable by rum.cs.yale.edu id h4LMTFx6001279 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Emacs development discussions. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:14069 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:14069 > When Emacs loads a file (that is supposed to be encoded in for example > ISO 2022, a 7 bit based encoding), does it first load the file > contents into a buffer as ASCII text and then applies > decode-coding-region to the entire buffer (conceptually)? It's optimized, but conceptually, yes, that's what it does. > Using decode-coding-region modifies the buffer contents because the > actual characters present in the buffer change (the two characters AA > might become the character =C5 or whatever, and hence the buffer > contents has been modified). (let ((mod (buffer-modified-p))) (decode-coding-region start end) (restore-buffer-modified-p mod)) Why does it matter if the buffer is "modified" or not ? I still don't get it. Note, I'm not trying to turn you away, but I really don't understand. > 1. I like the simple model of Rmail seeing a message as a narrowed > down part of the actual mail folder file (that is, no separate > display buffer). What do you like about it, other than the concept ? > 2. It would be desirable that Rmail didn't modify the underlying > message (=3D save decoded message), at least save it to disk. I have trouble parsing this sentence. Could you describe very concretely what you want to do ? Do you want to stores emails in fully decoded form in the Rmail file ? If so, why wouldn't "fully decoded" use the emacs-mule coding-system ? > Number 2 leads, due to the strong association between the message and > the mail folder file, that it also is undesirable to modify the > buffer, which is what decode-coding-region does. Instead, why not > decode the parts of the file that are encoded in a different manner > "correctly" the first time? Why does it matter whether it's the first time or the second ? In either case, it's different and needs to be re-encoded when saving. > Gnus doesn't have Rmails strong association of the message actually > being a narrowed down region of the mail folder file. It is fine for > Gnus to create a separate buffer wholly intended for working with the > message. That is why Gnus can load the encoded data into the buffer, > do decode-coding-region, insert buttons and play around with the > buffer contents--the buffer will be thrown away later. Yup, it's a very clean way to do things, indeed. You can decode all you want, throw stuff away, rewrite it, etc to your heart's content while still being 100% sure that you didn't mess up anything. Also it can be significantly more efficient since working on a 10KB display buffer is more efficient than working on a 100MB Rmail folder file. Sounds like a winner to me ;-) Which part do you not like ? Admittedly, when you don't have much to do to make the message "viewable"= , copying the message to a separate buffer is a waste and is less efficient than just narrow-and-go. Is that what bothers you ? > >> Though I can't come up with any other uses except for the proposed > >> Rmail usage for different coding-systems for different regions, I > >> don't see how it is nonsense. It is like opening a file constructed > >> by concatenating several files with different character encodings (a= nd > >> knowledge of what part of the file uses what encoding qould be > >> extracted from the MIME data). Do you see what I'm trying to > >> accomplish? > > > > I still don't understand what you want that's not already present. >=20 > I don't want to first load encoded data into the buffer, then decode > it (thereby modifying the contents). I want the decoding to happen > before the characters hit the Emacs buffer. And I want to use > different decoding for different parts of the underlying raw bytes. That describes *how* you want to reach your goal, but it doesn't describe your goal. Stefan