Subject: Re: bug#7651: 23.2.91; Rmail doesn't allow displaying text attachments conveniently

From: Eli Zaretskii <[email-masked]>
Date: Sat, 01 Jan 2011 13:00:44 +0200

> From: Kenichi Handa <[email-masked]>
> Cc: [email-masked], [email-masked]
> Date: Fri, 24 Dec 2010 13:50:48 +0900
> 
> In article <[email-masked]>, Kenichi Handa <[email-masked]> writes:
> > I hope I can commit related changes within this week.
> 
> I've just committed several changes to improve MIME
> handling.  Attached is the relevant part of NEWS.  Rmail
> users please check the new behavior.

Thanks.  I just started using it.  It is much better now.  I have only
a couple of minor issues to report so far:

 . Sometimes, in a multi-part message, it displays only a header, with
   no body and no buttons to toggle its display, save it to a file,
   etc.  Like this (in the RMAIL buffer, this is flushed all the way
   to the left margin):

     [2:text/html]

   It looks like this happens only for text/html parts, btw.
   Nevertheless, bodies of some text/html parts _are_ displayed.  The
   only difference I could spot is that those which are displayed have
   an <html> tag at their beginning.

 . When point is on the header line of part N, TAB moves to the
   beginning of the first line of the body of that part, not to the
   header of the next part (N+1).  Is this intentional?  If so, what
   is the reason for this behavior?

 . I wonder whether it will make more sense to bind mouse-1, rather
   than mouse-2, to push-button on the "Toggle show/hide" button.
   After all, the default binding of mouse-1 on that spot is not
   useful.

More importantly, bug #7626 is still not resolved fully, although some
of the more blatant parts of it (like keeping the encoding of the
previously displayed message) are gone.  I will report about that
separately, in that bug.

Thanks a lot for working on this.  I think this bug could be closed
after dealing with the above issues; if there are other problems, they
could be filed as separate bugs.