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: Thu, 22 May 2003 12:41:20 +0900 Organization: The XEmacs Project Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <878yszvean.fsf@tleepslib.sk.tsukuba.ac.jp> References: <200305211953.h4LJr9Iq000699@rum.cs.yale.edu> <200305212229.h4LMTFKo001277@rum.cs.yale.edu> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1053574956 11605 80.91.224.249 (22 May 2003 03:42:36 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 22 May 2003 03:42:36 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Thu May 22 05:42: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 19IgyC-000304-00 for ; Thu, 22 May 2003 05:42:20 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 19Ih9H-0007M5-00 for ; Thu, 22 May 2003 05:53:47 +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 19Igz2-0000e0-0J for emacs-devel@quimby.gnus.org; Wed, 21 May 2003 23:43:12 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19Igyi-0000aJ-05 for emacs-devel@gnu.org; Wed, 21 May 2003 23:42:52 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19IgyB-0008P6-UF for emacs-devel@gnu.org; Wed, 21 May 2003 23:42:51 -0400 Original-Received: from tleepslib.sk.tsukuba.ac.jp ([130.158.98.109]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19IgyA-0008L5-Rc for emacs-devel@gnu.org; Wed, 21 May 2003 23:42:19 -0400 Original-Received: from steve by tleepslib.sk.tsukuba.ac.jp with local (Exim 3.36 #1 (Debian)) id 19IgxE-0008S8-00; Thu, 22 May 2003 12:41:20 +0900 Original-To: stktrc In-Reply-To: (stktrc@yahoo.com's message of "Thu, 22 May 2003 03:25:36 +0200") User-Agent: Gnus/5.1001 (Gnus v5.10.1) XEmacs/21.5 (carrot, linux) 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:14076 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:14076 >>>>> "stktrc" == stktrc writes: stktrc> Because modifying the buffer means modifying the stktrc> underlying file (because Rmail writes the buffer back to stktrc> the file on exit for various reasons, message flags are stktrc> one I suppose). This is why I originally switched to VM. Rmail was unable to read, and sometimes trashing[1], my mail files, which contained mixed Japanese/ASCII/European encodings, and all of Unix/DOS/Macintosh newline conventions. We're not in Kansas anymore, Toto, and the Rmail "narrow-to-message" model simply increases complexity dramatically because of the underlying Mule model of coding-per-file. (Which is hard to see how you can avoid it.) stktrc> I'm not totally opposed to that approach. It is an stktrc> alternative, but as stated before, I like the one folder - stktrc> one buffer concept for it's simplicity. Fine. This will go gangbusters if you set your spamassassin to throw away all mail with "Content-Type" headers. Now the world is simple enough to fit into that concept well. Otherwise, there are at least two radically different views of many files, and there must be a buffer (in the generic sense of a separate region of memory) for presentation, and one for the much more restricted changes you wish propagated back to the file (setting flags). I see no good reason why the region of memory used for presentation shouldn't "waste" a few score bytes and be promoted to an Emacs buffer. stktrc> I thought there was a layer between the file system and stktrc> the Emacs buffer that decoded the bytes from the file into stktrc> characters that were inserted into the buffer (and the stktrc> other way when writing). That is, the buffer would never stktrc> see the encoded data, it would just receive already stktrc> decoded characters in an Emacs internal representation. stktrc> If it had been like this, It is like that in practice, most of the time. But it's only practical for simple cases, eg, where the whole file is encoded in one encoding, or the whole file conforms to a fixed standard such as ISO 2022. Multimedia (in the MIME sense) files can't work that way. The meta-information used to create the presentation is often a hint, or a user option. stktrc> with the addition of the possibility of different stktrc> decodings for different parts, it could have been used for stktrc> the purposes described earlier (to display MIME messages stktrc> as if they had been decoded inline *without modifying* the stktrc> buffer). But then how do you save the buffer (eg, if you have set flags)? It differs from the file, and the decoding process is not an isomorphism (multimedia). Footnotes: [1] Many years ago. And the trashed cases required a very special configuration of very non-RFC-conformant messages. Unfortunately, these were quite common in Japan ca. 1994. The Internet can be a very hostile place! -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software