From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Richard Stallman 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 19:19:40 -0400 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <200305211953.h4LJr9Iq000699@rum.cs.yale.edu> <200305212229.h4LMTFKo001277@rum.cs.yale.edu> <878yszvean.fsf@tleepslib.sk.tsukuba.ac.jp> <87wughogc8.fsf@tleepslib.sk.tsukuba.ac.jp> Reply-To: rms@gnu.org NNTP-Posting-Host: main.gmane.org X-Trace: main.gmane.org 1053818676 6378 80.91.224.249 (24 May 2003 23:24:36 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sat, 24 May 2003 23:24:36 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Sun May 25 01:24:34 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 19JiNN-0001eg-00 for ; Sun, 25 May 2003 01:24:33 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 19JiZp-00059K-00 for ; Sun, 25 May 2003 01:37:26 +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 19JiMu-0005Hc-4k for emacs-devel@quimby.gnus.org; Sat, 24 May 2003 19:24:04 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19JiLp-0004tO-JV for emacs-devel@gnu.org; Sat, 24 May 2003 19:22:57 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19JiJI-0004M4-Ga for emacs-devel@gnu.org; Sat, 24 May 2003 19:20:21 -0400 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19JiIe-000443-Ix for emacs-devel@gnu.org; Sat, 24 May 2003 19:19:40 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.20) id 19JiIe-0007dN-5S; Sat, 24 May 2003 19:19:40 -0400 Original-To: "Stephen J. Turnbull" In-reply-to: <87wughogc8.fsf@tleepslib.sk.tsukuba.ac.jp> (stephen@xemacs.org) 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:14208 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:14208 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. It is important to have a way to edit the text that is displayed. It is desirable but not very important to preserve the first charset designation. If we can't do both, we should do the former. 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). This is easy to do--just don't replace the original text unless the user has edited the message. The user must type an explicit command, currently e, to edit the message. The edited text would be stored back into the file only when the user exits edit mode (and not if he aborts the edit). In addition, it is easy to compare the buffer contents with what is produced by preparing the original message for display. If they are the same, then don't alter the original message text. 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. Right now, if I switch to buffer RMAIL, I see the message that is selected in the buffer RMAIL. If that message is actually displayed in another buffer, then switching to RMAIL won't show it, or won't show it properly. Perhaps we need a feature of "alias buffers". If we set up buffer RMAIL to specify buffer *View RMAIL* as its alias, then when buffer RMAIL is selected in a window, buffer *View RMAIL* will actually appear in the window and will actually be the current buffer most of the time. (You could still make RMAIL the current buffer by explicitly calling set-buffer.) Tar mode could also make use of this. And Info.