From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Different (buffer-file-)coding-systems for different regions of one buffer? (for Rmail MIME) Date: Sat, 24 May 2003 00:03:35 +0900 Organization: The XEmacs Project Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <87wughogc8.fsf@tleepslib.sk.tsukuba.ac.jp> References: <200305211953.h4LJr9Iq000699@rum.cs.yale.edu> <200305212229.h4LMTFKo001277@rum.cs.yale.edu> <878yszvean.fsf@tleepslib.sk.tsukuba.ac.jp> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1053703628 13541 80.91.224.249 (23 May 2003 15:27:08 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Fri, 23 May 2003 15:27:08 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Fri May 23 17:27:05 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 19JEMK-0002v9-00 for ; Fri, 23 May 2003 17:21:28 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 19JEY8-0003Wp-00 for ; Fri, 23 May 2003 17:33:40 +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 19JEBR-0004xL-4C for emacs-devel@quimby.gnus.org; Fri, 23 May 2003 11:10:13 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19JE8e-0004KA-Dd for emacs-devel@gnu.org; Fri, 23 May 2003 11:07:20 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19JE6e-0003ZT-76 for emacs-devel@gnu.org; Fri, 23 May 2003 11:05:22 -0400 Original-Received: from tleepslib.sk.tsukuba.ac.jp ([130.158.98.109]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19JE56-0001fX-ID; Fri, 23 May 2003 11:03:40 -0400 Original-Received: from steve by tleepslib.sk.tsukuba.ac.jp with local (Exim 3.36 #1 (Debian)) id 19JE52-0002DS-00; Sat, 24 May 2003 00:03:36 +0900 Original-To: rms@gnu.org In-Reply-To: (Richard Stallman's message of "Fri, 23 May 2003 08:03:52 -0400") User-Agent: Gnus/5.1001 (Gnus v5.10.1) XEmacs/21.5 (carrot, linux) Original-cc: stktrc@yahoo.com 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:14138 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:14138 >>>>> "rms" == Richard Stallman writes: rms> It pretty much has to be an Emacs buffer, or part of one. rms> There is no other natural or easy way to implement it in the rms> context of Emacs. The question would be, is it a separate rms> buffer, or a part of another buffer, or what? If you want to preserve the original contents of the buffer, you must copy them somewhere, because many of the transformations performed to make text displayable are not invertible. For example, it is perfectly legal in ISO 2022 coding systems to have two charset designations with no intervening text. The first one will get lost. Messages from older MUAs may contain the so-called abbreviated escape sequences for Japanese and Chinese; a modern one would write them out in the longer form. It is almost always possible to unify ISO 8859/1 and ISO 8859/15 to ISO 8859/15, yet with cut and paste under current situation, Emacs will produce a buffer with multiple charsets. However, Emacs may or may not attempt to unify those charsets on write, depending, I believe, on user options. Quoted-printable, division of MIME encoded-words, and so on all present similar issues. Of course all of these could be handled by setting a text property saying "in the original this was ISO 8859/1 but it has been unified to ISO 8859/2" or putting an invisible property on a redundant escape sequence and leaving it in the buffer, but that's ugly and fault-prone. rms> In Rmail currently it is possible to type e and edit a rms> message. Right now we do this through editing the buffer of rms> the RMAIL file. With better MIME support, this may have to rms> be implemented differently, but I hope we can keep it working rms> somehow. I think this will require a lot of work if you wish to preserve file text verbatim unless explicitly edited (and this is essential for signed messages, for example). rms> If we copy the message into another buffer for viewing, that rms> tends to lead to complications of the situation, because rms> there are multiple buffers instead of just one. We could try rms> adding features to hide that, or we could expose it and not rms> hide anything. I don't see how it gets complicated. You put a couple of markers in the original buffer, copy the region to the presentation buffer, and transform it. If you don't edit it, (erase-buffer) and go on to the next message. If you want to edit, you edit the presentation buffer, in exactly the same way that currently you would edit the Rmail buffer. Once you've changed the presentation buffer, I see no reason not to unify charsets, remove redundant escape sequences, and so on. Once you're done, you simply replace the marked region in the original buffer. Reversion is simple: you refresh from the original buffer, no messing with undo etc. In this model, the only operations you perform on the original buffer are (1) visible header movement, (2) setting flags in Rmail-specific headers, and (3) replacement of the whole message with an edited version. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp Universi