From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Alexander Pohoyda Newsgroups: gmane.emacs.devel Subject: Re: RMAIL, MIME clean-up, coding system Date: Sun, 12 Oct 2003 22:33:21 +0200 (CEST) Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <200310122033.h9CKXLQA006333@oak.pohoyda.family> References: <200310080542.h985gNkp000541@oak.pohoyda.family> NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1065990995 10789 80.91.224.253 (12 Oct 2003 20:36:35 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 12 Oct 2003 20:36:35 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Sun Oct 12 22:36:33 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 1A8mx7-0006Zv-00 for ; Sun, 12 Oct 2003 22:36:33 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1A8mx6-0002qy-00 for ; Sun, 12 Oct 2003 22:36:33 +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 1A8muw-0001zP-6u for emacs-devel@quimby.gnus.org; Sun, 12 Oct 2003 16:34:18 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1A8mue-0001vC-HB for emacs-devel@gnu.org; Sun, 12 Oct 2003 16:34:00 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1A8mu7-0001de-1b for emacs-devel@gnu.org; Sun, 12 Oct 2003 16:33:59 -0400 Original-Received: from [213.165.64.20] (helo=mail.gmx.net) by monty-python.gnu.org with smtp (Exim 4.24) id 1A8mu6-0001dI-DF for emacs-devel@gnu.org; Sun, 12 Oct 2003 16:33:26 -0400 Original-Received: (qmail 12192 invoked by uid 65534); 12 Oct 2003 20:33:21 -0000 Original-Received: from p508BF1A1.dip.t-dialin.net (EHLO oak.pohoyda.family) (80.139.241.161) by mail.gmx.net (mp004) with SMTP; 12 Oct 2003 22:33:21 +0200 X-Authenticated: #14602519 Original-Received: from oak.pohoyda.family (oak.pohoyda.family [127.0.0.1]) by oak.pohoyda.family (8.12.9/8.12.9) with ESMTP id h9CKXLR4006336; Sun, 12 Oct 2003 22:33:21 +0200 (CEST) (envelope-from apog@oak.pohoyda.family) Original-Received: (from apog@localhost) by oak.pohoyda.family (8.12.9/8.12.9/Submit) id h9CKXLQA006333; Sun, 12 Oct 2003 22:33:21 +0200 (CEST) (envelope-from apog) Original-To: rms@gnu.org In-Reply-To: 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:17048 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:17048 Richard Stallman writes: > That's exactly what I have proposed: to encode them (text > bodyparts) back into US-ASCII stream using base64 method. > > I am not really sure what that means. Could you explain? The basic problem is here once again: We read emails from inbox file and store them into RMAIL file, doing some processing on the way. This processing includes base64 and quoted-printable decoding. Now, to export this email back to file (rmail-output function) we have two ways: a) write it using emacs-mule coding system; b) encode bodyparts which need to be encoded using base64 or quoted-printable "transfer encoding" and save the file as US-ASCII. Solution (a) has a clear disadvantage that such a file may only be visited by Emacs. Well, this is such a big disadvantage that I don't buy this solution at all. Solution (b) is more complicated and, in fact, does the action reversed to what we did with an email in the first place. Hopefully we don't have to do this too often. So another question arises: does it make sence to do the initial processing in the first place? The fact is that we already do some processing, namely: we insert the extra "simplified" header between the original header and the message body. Both solutions do not need the X-Coding-System header field, which I mentioned before. Do I oversee something? > Anyway, the first idea that occurs to me is to edit the headers of > the mime attachments to say how they are really encoded. Why not? Yes, this is already done. Imagine that we have a message with two bodyparts of type text/plain. One of them is encoded using koi8-r and another is a utf-8 text. We know this, and we can show the message in the buffer. The problem is here: how to export it into the file? -- Alexander Pohoyda PGP Key fingerprint: 7F C9 CC 5A 75 CD 89 72 15 54 5F 62 20 23 C6 44