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: Mon, 26 May 2003 14:20:54 +0900 Organization: The XEmacs Project Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <87brxql1vt.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> <87wughogc8.fsf@tleepslib.sk.tsukuba.ac.jp> 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 1053926472 31006 80.91.224.249 (26 May 2003 05:21:12 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 26 May 2003 05:21:12 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Mon May 26 07:21:11 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 19KAPY-00082X-00 for ; Mon, 26 May 2003 07:20:40 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 19KAcb-0007I9-00 for ; Mon, 26 May 2003 07:34:09 +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 19KARH-0002aj-BY for emacs-devel@quimby.gnus.org; Mon, 26 May 2003 01:22:27 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19KAQy-0002YO-3d for emacs-devel@gnu.org; Mon, 26 May 2003 01:22:08 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19KAQN-00029S-4j for emacs-devel@gnu.org; Mon, 26 May 2003 01:21:32 -0400 Original-Received: from tleepslib.sk.tsukuba.ac.jp ([130.158.98.109]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19KAPt-00021M-Eg; Mon, 26 May 2003 01:21:01 -0400 Original-Received: from steve by tleepslib.sk.tsukuba.ac.jp with local (Exim 3.36 #1 (Debian)) id 19KAPo-0002vb-00; Mon, 26 May 2003 14:20:56 +0900 Original-To: rms@gnu.org In-Reply-To: (Richard Stallman's message of "Sat, 24 May 2003 19:19:40 -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:14272 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:14272 >>>>> "rms" =3D=3D Richard Stallman writes: 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. rms> It is important to have a way to edit the text that is rms> displayed. It is desirable but not very important to rms> preserve the first charset designation. That's assuming that it is text. This implementation would make corruption of attached binaries likely and signed messages somewhat likely (I haven't done a survey to see how many redundant designations are in my text mail files in about 6 years, but in 1997 there were a fair number; about 1 every 20 Japanese messages). rms> If we can't do both, we should do the former. I don't see why editing the presentation buffer, then replacing the region in the full buffer, doesn't satisfy this requirement. 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> This is easy to do--just don't replace the original text rms> unless the user has edited the message. But you don't have the original text any more (except in the disk file). You have decoded text in the buffer. When you save that, you will lose redundant ISO 2022 designations and directional sequences, you will lose "naked newlines" in DOS files. You will likely lose the exactly format of decoded MIME words in headers in embedded messages. And remember, if you implement this as an "rmail-coding-system", _all_ messages in the buffer will be automatically decoded. It is not just the current message whose corruption is being risked. rms> The user must type an explicit command, currently e, to edit rms> the message. The edited text would be stored back into the rms> file only when the user exits edit mode (and not if he aborts rms> the edit). If you change the displayed buffer at all (eg, to set a READ flag), you save the decoded buffer contents. These are in general different at the binary level from what is on disk, and must be encoded. ISO 2022 and MIME do not guarantee that decoding is invertible, and in fact often the originating and receiving functions are different implementations, and are not inverses. 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. rms> Right now, if I switch to buffer RMAIL, I see the message rms> that is selected in the buffer RMAIL. If that message is rms> actually displayed in another buffer, then switching to RMAIL rms> won't show it, or won't show it properly. Kai Gro=DFjohann's answer to this (rename the presentation buffer to RMAIL, users rarely will want to see the full buffer, so it can be renamed to a "hidden" buffer name) is correct as far as I can tell from my own experience, convenient for the user, and easily implemented. It's even convenient for third-party developers who provide add-on facilities, as they don't need to worry so much about buffer restrictions as under Rmail. I used to find that a major annoyance (admittedly, I was a rather unskilled Lisp programmer when I was using Rmail). You are right that this is a potential problem. Both VM and Gnus try to maintain "window configurations", and they occasionally get it wrong. It's easy to work around, but annoying when it happens. However, their window configurations are much more complex than the scheme Kai suggested, and I think the probability of it causing problems is very low. AFAIK Rmail is the only remaining major Emacs MUA that handles mail folders implemented as single files by transforming to display format in place in a single buffer. In fact, IIRC VM switched from Rmail- style "full-buffer-is-display-buffer" for text-only messages relatively recently (it always had presentation buffers, but restricted them to multimedia messages, eg, containing images or audio). While that's not in itself a good reason for Rmail to switch, I think it tends to indicate that difficulty of implementation is not so great as you think. --=20 Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac= .jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JA= PAN Ask not how you can "do" free software business; ask what your business can "do for" free software.