GNU bug report logs - #10078
23.3; Rmail's rmail-mine command (v) does not correctly display raw message when rmail-enable mime is true (default)

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 10078 in the body.
You can then email your comments to 10078 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Mark Lillibridge <mark.lillibridge <at> hp.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 23.3;
	Rmail's rmail-mine command (v) does not correctly display raw message
	when rmail-enable mime is true (default)
Date: Sat, 19 Nov 2011 13:17:33 -0800

    This is probably more of a command fails to do the expected and
useful thing rather than strictly a bug.  The help documentation for
this command is as follows:

   v runs the command rmail-mime, which is an interactive compiled Lisp
   function in `rmailmm.el'.

   It is bound to v.

   (rmail-mime &optional ARG)

   Toggle displaying of a MIME message.

   The actualy behavior depends on the value of `rmail-enable-mime'.

   If `rmail-enable-mime' is t (default), this command change the
   displaying of a MIME message between decoded presentation form
   and raw data.

   With ARG, toggle the displaying of the current MIME entity only.

   If `rmail-enable-mime' is nil, this creates a temporary
   "*RMAIL*" buffer holding a decoded copy of the message.  Inline
   content-types are handled according to
   `rmail-mime-media-type-handlers-alist'.  By default, this
   displays text and multipart messages, and offers to download
   attachments as specfied by `rmail-mime-attachment-dirs-alist'.


    From "displaying of a MIME message between decoded presentation form
and raw data", I would assume this command would toggle between the
normal display of a message and it's raw undecoded form.  What it
actually does is a very weird hybrid where you get raw data for the
parts but the boundaries are still decoded (e.g., missing).  An example
probably helps here.  Consider the following message as it is normally
presented:

Date: Sat, 19 Nov 2011 13:02:35 -0800
Subject: this message has a text and HTML part
From: Mark Lillibridge <lillibridge <at> gmail.com>
To: mdl <at> alum.mit.edu

[1:text/plain Hide]
*this *is bold.
[2:text/html Show]


    When you hit 'v', this switches to (I've replaced a lot of headers
with ...):

From mdl  Sat Nov 19 13:03:52 2011
Return-Path: <lillibridge <at> gmail.com>
Received: from pobox-pa.hpl.hp.com [15.25.112.25]
	by ts-rhel5 with IMAP (fetchmail-6.3.6)
	for <mdl <at> localhost> (single-drop); Sat, 19 Nov 2011 13:03:52 -0800 (PST)
...
MIME-Version: 1.0
Message-ID: <CAHBhPjX1He3imxDDqoFVmLM=P+vUAh--qL+HtuTSjFy39pB=mQ <at> mail.gmail.com>
Subject: this message has a text and HTML part
From: Mark Lillibridge <lillibridge <at> gmail.com>
To: mdl <at> alum.mit.edu
Content-Type: multipart/alternative; boundary=bcaec53aec3ee5f3fe04b21cc50d
...
X-RMAIL-ATTRIBUTES: --------

Content-Type: text/plain; charset=ISO-8859-1

*this *is bold.
Content-Type: text/html; charset=ISO-8859-1

<b>this </b>is bold.<br><br>


    For comparison, the actual raw message body looks like:

--bcaec53aec3ee5f3fe04b21cc50d
Content-Type: text/plain; charset=ISO-8859-1

*this *is bold.

--bcaec53aec3ee5f3fe04b21cc50d
Content-Type: text/html; charset=ISO-8859-1

<b>this </b>is bold.<br><br>

--bcaec53aec3ee5f3fe04b21cc50d--


    I can't for the life of me figure out what the hybrid version is
useful for.  It's very hard to tell where the different parts begin and
end.  This command can individually toggle parts to showing raw decoding
via C-u v; for example, here's what it looks like with only the second
part decoded:

Date: Sat, 19 Nov 2011 13:02:35 -0800
Subject: this message has a text and HTML part
From: Mark Lillibridge <lillibridge <at> gmail.com>
To: mdl <at> alum.mit.edu

[1:text/plain Hide]
*this *is bold.
Content-Type: text/html; charset=ISO-8859-1

<b>this </b>is bold.<br><br>


    I don't understand why this is useful either.  Can someone please
explain why either of these abilities are useful?  I know do want the
the show raw message command from to time to time and that is what the
help message seems to promise so I'd recommend replacing the current 'v'
functionality (with rmail-enable-mime t) with a simple toggle to show
raw message command.  This would have the advantage of also being
symmetrical with the rmail-enable-mime nil case.

- Mark

Message #8 received at 10078 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: mark.lillibridge <at> hp.com
Cc: 10078 <at> debbugs.gnu.org
Subject: Re: bug#10078: 23.3;
	Rmail's rmail-mine command (v) does not correctly display raw
	message	when rmail-enable mime is true (default)
Date: Sun, 20 Nov 2011 05:51:56 +0200

> From: Mark Lillibridge <mark.lillibridge <at> hp.com>
> Date: Sat, 19 Nov 2011 13:17:33 -0800
> 
>     I can't for the life of me figure out what the hybrid version is
> useful for.

It is mainly useful for MIME messages with attachments.

Message #11 received at 10078 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 10078 <at> debbugs.gnu.org, mark.lillibridge <at> hp.com
Subject: Re: bug#10078: 23.3;
	Rmail's rmail-mine command (v) does not correctly display raw
	message	when rmail-enable mime is true (default)
Date: Wed, 23 Nov 2011 20:51:02 -0500

Eli Zaretskii wrote:

>>     I can't for the life of me figure out what the hybrid version is
>> useful for.
>
> It is mainly useful for MIME messages with attachments.

I don't get it. In "raw" form, an attachment is hundreds or thousands of
lines of gobbledygook, whereas a mime boundary is a line or so of
somewhat readable text. How is it useful to show the former but hide the
latter? Especially since the various Content-Type headers are shown.


There definitely needs to be _some_ command that completely undoes what
rmail-mime does to a message. Then rmailedit could use it instead of the
hack it uses now (bug#9840). If not rmail-mime, then `rmail-unmime' or
somesuch.

Message #14 received at 10078 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 10078 <at> debbugs.gnu.org, mark.lillibridge <at> hp.com
Subject: Re: bug#10078: 23.3;
	Rmail's rmail-mine command (v) does not correctly display raw
	message	when rmail-enable mime is true (default)
Date: Thu, 24 Nov 2011 06:00:23 +0200

> From: Glenn Morris <rgm <at> gnu.org>
> Cc: mark.lillibridge <at> hp.com,  10078 <at> debbugs.gnu.org
> Date: Wed, 23 Nov 2011 20:51:02 -0500
> 
> Eli Zaretskii wrote:
> 
> >>     I can't for the life of me figure out what the hybrid version is
> >> useful for.
> >
> > It is mainly useful for MIME messages with attachments.
> 
> I don't get it. In "raw" form, an attachment is hundreds or thousands of
> lines of gobbledygook, whereas a mime boundary is a line or so of
> somewhat readable text. How is it useful to show the former but hide the
> latter? Especially since the various Content-Type headers are shown.

FWIW, I have nothing against showing the MIME boundary as well.

Message #17 received at 10078 <at> debbugs.gnu.org (full text, mbox):

From: Richard Stallman <rms <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rgm <at> gnu.org, 10078 <at> debbugs.gnu.org, mark.lillibridge <at> hp.com
Subject: Re: bug#10078: 23.3;
	Rmail's rmail-mine command (v) does not correctly display raw
	message	when rmail-enable mime is true (default)
Date: Thu, 24 Nov 2011 13:32:28 -0500

    FWIW, I have nothing against showing the MIME boundary as well.

I thought of trying to make it show that, but I couldn't understand
the code very well, and could not do it.  Then I saw that displaying
the code exactly as it appears in the file achieved the same goal
and was easy.  So I did it that way.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

Message #20 received at 10078 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: rms <at> gnu.org
Cc: Eli Zaretskii <eliz <at> gnu.org>, 10078 <at> debbugs.gnu.org,
	mark.lillibridge <at> hp.com
Subject: Re: bug#10078: 23.3;
	Rmail's rmail-mine command (v) does not correctly display raw
	message	when rmail-enable mime is true (default)
Date: Thu, 24 Nov 2011 13:52:04 -0500

Richard Stallman wrote:

>     FWIW, I have nothing against showing the MIME boundary as well.
>
> I thought of trying to make it show that, but I couldn't understand
> the code very well, and could not do it.

Me neither...

> Then I saw that displaying the code exactly as it appears in the
> file achieved the same goal and was easy. So I did it that way.

What function are you referring to here?
How do you "displaying the code exactly as it appears in the file"?

Message #23 received at 10078 <at> debbugs.gnu.org (full text, mbox):

From: Richard Stallman <rms <at> gnu.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: eliz <at> gnu.org, 10078 <at> debbugs.gnu.org, mark.lillibridge <at> hp.com
Subject: Re: bug#10078: 23.3;
	Rmail's rmail-mine command (v) does not correctly display raw
	message	when rmail-enable mime is true (default)
Date: Fri, 25 Nov 2011 11:48:49 -0500

    What function are you referring to here?
    How do you "displaying the code exactly as it appears in the file"?

Sorry, I mean display it without mime processing.  I don't remember
which function it was, but ChangeLog should show.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.