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: Tue, 27 May 2003 19:03:28 +0900 Organization: The XEmacs Project Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <87u1bgiu4v.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> <87brxql1vt.fsf@tleepslib.sk.tsukuba.ac.jp> <2561-Mon26May2003203019+0300-eliz@elta.co.il> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1054030004 25323 80.91.224.249 (27 May 2003 10:06:44 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 27 May 2003 10:06:44 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Tue May 27 12:06:42 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 19KbLj-0006ZM-00 for ; Tue, 27 May 2003 12:06:31 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 19KbZM-0007Ut-00 for ; Tue, 27 May 2003 12:20:37 +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 19KbLS-0003pV-Ty for emacs-devel@quimby.gnus.org; Tue, 27 May 2003 06:06:14 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19KbJo-00036T-QY for emacs-devel@gnu.org; Tue, 27 May 2003 06:04:32 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19KbJZ-0002hg-Py for emacs-devel@gnu.org; Tue, 27 May 2003 06:04: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 19KbIv-0001uM-He for emacs-devel@gnu.org; Tue, 27 May 2003 06:03:37 -0400 Original-Received: from steve by tleepslib.sk.tsukuba.ac.jp with local (Exim 3.36 #1 (Debian)) id 19KbIn-0007oc-00; Tue, 27 May 2003 19:03:29 +0900 Original-To: Eli Zaretskii In-Reply-To: <2561-Mon26May2003203019+0300-eliz@elta.co.il> (Eli Zaretskii's message of "Mon, 26 May 2003 20:30:19 +0300") 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:14309 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:14309 >>>>> "Eli" == Eli Zaretskii writes: Eli> Aren't attachments clearly marked in the message as being Eli> such? Can't Emacs look for those markers (the part Eli> delimiters in a multi-part message) and refrain from decoding Eli> binary data while decoding text? Yes and yes. It's complex, though, and coding is not an area where you want that. For example, consider that the state of the buffer is fragile, partly decoded to multibyte and partly raw unibyte. Failure to handle an error while decoding risks crashes. Eli> I see one significant disadvantage of this design: it will Eli> require thorough rewrite of many parts in RMAIL, since the Eli> code as it is now assumes a single buffer, narrowed as Eli> required. I don't have enough information and experience to Eli> judge whether this is a serious disadvantage, though. It's surely possible to maintain the single buffer model by adding a mail-coding-system. But I think that will make the code less modular, require extensive duplication of existing functionality, be harder to maintain, and present greater risk of undetected corruption (and even crashes) than using the presentation buffer model. I've presented my opinion, but that's all it is. At the very least it exposes some of the potential pitfalls, and thus could help with dealing with them. -- 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.