Re: rmailmime.el

Re: rmailmime.el

[Richard Stallman]

I see that rmailmime.el invokes metamail.el,
and metamail seems to feed the message to metamail.
But what does that actually do?

I tried it on one message which had a mime part with type text/plain
and another with type text/html.

What it did was create another window which showed something like
(end) -- but nothing else.  I think it runs vi.  That's not very
useful.  Running another Emacs wouldn't be very useful either.

I typed q and it said to type another character to proceed.  I typed a
space and that window went away, and the text/html stuff showed up
in BurningDog.  That makes sense.  But the behavior overall is
not convenient.

When all that is finished, I see a buffer called *metamail* which
seems to contain a processed version of the message header.  What is
the purpose of that?  Is there something useful I can do with it?

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.

Would someone like to implement a mode like that?

Re: rmailmime.el

[Masanobu UMEDA]

   From: Richard Stallman <rms@gnu.org>
   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

Re: rmailmime.el

[Richard Stallman]

    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.

In some cases it can be decoded in the current buffer.
The very simple mime-handler I use does that for quoted-printable.
For base64, by contrast, it puts the attachment text into another buffer.
I decided to do it that way because the things that are encoded in base64
are often not text at all; they are jpeg or pdf, for instance.

But if we use metamail to handle the other formats in a special way,
then text which is encoded in base64 could be decoded in the same
buffer.