From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: RMAIL, MIME-related bug Date: 16 Oct 2003 18:07:41 -0400 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <200310121947.h9CJlhKH006102@oak.pohoyda.family> <8765ioc0yi.fsf@oak.pohoyda.family> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1066342205 10105 80.91.224.253 (16 Oct 2003 22:10:05 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 16 Oct 2003 22:10:05 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Fri Oct 17 00:10:01 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AAGJl-0006UM-00 for ; Fri, 17 Oct 2003 00:10:01 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1AAGJl-000725-00 for ; Fri, 17 Oct 2003 00:10:01 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AAGJF-0004d0-QR for emacs-devel@quimby.gnus.org; Thu, 16 Oct 2003 18:09:29 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AAGID-0004HU-Eu for emacs-devel@gnu.org; Thu, 16 Oct 2003 18:08:25 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AAGHf-00047O-RH for emacs-devel@gnu.org; Thu, 16 Oct 2003 18:08:23 -0400 Original-Received: from [132.204.24.67] (helo=mercure.iro.umontreal.ca) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AAGHd-00046i-Lu for emacs-devel@gnu.org; Thu, 16 Oct 2003 18:07:49 -0400 Original-Received: from vor.iro.umontreal.ca (vor.iro.umontreal.ca [132.204.24.42]) by mercure.iro.umontreal.ca (8.12.9/8.12.9) with ESMTP id h9GM7gUN018125; Thu, 16 Oct 2003 18:07:42 -0400 Original-Received: by vor.iro.umontreal.ca (Postfix, from userid 20848) id 0A1623C63E; Thu, 16 Oct 2003 18:07:41 -0400 (EDT) Original-To: Alexander Pohoyda In-Reply-To: <8765ioc0yi.fsf@oak.pohoyda.family> Original-Lines: 36 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 X-DIRO-MailScanner: Found to be clean X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:17180 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:17180 >> Of course, you also need to keep the signed-text unless you're >> super-extra-careful to make sure that you can re-create the exact same >> byte-sequence from the rest of the data, which is rather unlikely. > OK, let's keep the signed text un-changed, but I would prefer to do > the decoding on normal messages. As Eli points out, this is logical > to do once on message arrival. I see nothing logical about it. AFAICT, the message will be saved somehow in a text file, so you'll need to use some kind of unambiguous textual representation of the various parts of the message. Of course, you can re-invent the wheel or use another existing wheel (the builtin lisp printer), but using the original MIME representation is a pretty natural choice. >> Why do people even consider doing any processing at that point? > Just to optimise the process. Doing it every time in show-message is > even simplier from the programmer's point of view. I'd first concentrate on getting something working correctly. Especially since there is no evidence that performance will be a problem, let alone that a pre-processed form will be more efficient. > You are right, but let's focus on the need not to invent the > RMAIL-MIME, no additional header in between the message. Do you agree > that hiding header fields is preferred to having two message headers? I don't really know the details of what this is referring to. I generally like approaches based on adding text-properties and overlays rather than modifying buffer text, but modifying buffer text can be much simpler, with fewer surprises and much more flexible (I like my headers to be sorted for example, which can't be done just by hiding undesirable header fields). Stefan