From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Masanobu UMEDA Newsgroups: gmane.emacs.devel Subject: Re: rmailmime.el Date: Thu, 27 Dec 2007 01:20:37 +0900 Message-ID: <200712261620.BAA23474@latour.cad.ci.kyutech.ac.jp> References: Reply-To: umerin@ci.kyutech.ac.jp NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Trace: ger.gmane.org 1198696033 24077 80.91.229.12 (26 Dec 2007 19:07:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 26 Dec 2007 19:07:13 +0000 (UTC) Cc: emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Dec 26 20:07:25 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1J7bb8-0004ks-7o for ged-emacs-devel@m.gmane.org; Wed, 26 Dec 2007 20:07:22 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J7ban-0003LY-Hi for ged-emacs-devel@m.gmane.org; Wed, 26 Dec 2007 14:07:01 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1J7Z0J-0000Cl-Hk for emacs-devel@gnu.org; Wed, 26 Dec 2007 11:21:11 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1J7Z0G-0000AD-Sy for emacs-devel@gnu.org; Wed, 26 Dec 2007 11:21:11 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J7Z0G-0000A9-OO for emacs-devel@gnu.org; Wed, 26 Dec 2007 11:21:08 -0500 Original-Received: from latour.cad.ci.kyutech.ac.jp ([131.206.67.77]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1J7Z0D-0007cE-3n; Wed, 26 Dec 2007 11:21:05 -0500 Original-Received: (from umerin@localhost) by latour.cad.ci.kyutech.ac.jp (8.9.3p2+3.2W/3.7W) id BAA23474; Thu, 27 Dec 2007 01:20:37 +0900 In-reply-to: (message from Richard Stallman on Sun, 23 Dec 2007 16:12:09 -0500) X-detected-kernel: by monty-python.gnu.org: Linux 2.2 (2) X-Mailman-Approved-At: Wed, 26 Dec 2007 14:06:58 -0500 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:85484 Archived-At: From: Richard Stallman Date: Sun, 23 Dec 2007 16:12:09 -0500 I see that rmailmime.el invokes metamail.el, and metamail seems to feed the message to metamail. But what does that actually do? What metamail does depends on your ~/.mailcap. Personally, I use it to decode and preview application-specific files, such as PDF. At first, I planned to reformat a MIME message into a tentative format that was used by mime.el, a simple MIME composer. But, at that time, Emacs did not support an easy way to show images in an Emacs buffer. Therefore, I suspended to realize the idea, and just used metamail tentatively. Unfortunately, I have no time to realize the idea right now :-< Following your idea will work well for text/plan of us-ascii charset in 7bit transfer-encoding. In case of quoted-printable or base64 encoding, or non-us-ascii charsets, even if a message is text/plain, it should be decoded and internalized according to its designated charset to display it in an Emacs buffer. This means that a message need to be decoded and its charset translated in an Emacs buffer. Here, we have two choices; this buffer content supersedes an original message in a RMAIL buffer, or this buffer is used only for display like metamail. The former approach is useful for users of non-us-ascii charsets, but it is necessary to rewrite a MIME header of an original message in a RMAIL buffer appropriately. The same problem exits in headers of an envelope. rmailmime.el provides rmail-convert-mime-header to rewrite MIME-encoded headers of an envelope as follows: (setq rmail-message-filter 'rmail-convert-mime-header) This function decodes and rewrites headers, such as Subject. Signed messages make things more complex, but let us forget about this now. It seems like the right thing to do is make the contents of the mime parts invisible, excepting the text/plain parts. And then if you click on one of the mime part headers followed by invisible contents, it should display that mime part via metamail. There could be commands such as C-c C-n and C-c C-p to move to the next or previous mime part header. I think it would be best not to pass any given mime part to metamail unless/until the user goes to it and asks to see that part. Masanobu Umeda