emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: rmailmime.el


From: Masanobu UMEDA
Subject: Re: rmailmime.el
Date: Thu, 27 Dec 2007 01:20:37 +0900

   From: Richard Stallman <address@hidden>
   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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]