bug-gnu-emacs
[Top][All Lists]
Advanced
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#7651: 23.2.91; Rmail doesn't allow displaying text attachments conve

From: Kenichi Handa
Subject: bug#7651: 23.2.91; Rmail doesn't allow displaying text attachments conveniently
Date: Tue, 04 Jan 2011 14:01:11 +0900 
In article <83vd28q46b.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:

>  . 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]

You still can toggle hide/show by typing RET while point is
on that tagline.

>    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.

By default, inline text/plain, message/rfc822, multipart/*
parts are shown with their bodies except for these cases.

If the top level mesage is text/html, the body is shown.  If
the text/html part is the only text/* part of a
multipart/alternative, the body of text/html is shown.

>  . 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?

It's intentional as described in the docstring of
rmail-mime-next-item.

----------------------------------------------------------------------
Move point to the next displayed item of the current MIME entity.
A MIME entity has three items; header, tagline, and body. 
----------------------------------------------------------------------

But there's no strong reason for that behavior.  I just
thought it's convenient if you can move to a body part by
TAB especially for a message/rfc822 part which is displayed
with header lines.

>  . 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.

For "Toggle show/hide" button, perhaps yes.  But for a
button of file saving, one may want to select the displayed
filename by mouse-1.  So mouse-2 is better.  Then, for
consistency, using mouse-2 also for "Toggle show/hide" may
be better.  But, I'm not sure because I uses only TAB and
RET.

> 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.

I'll check the code again for that problem.

---
Kenichi Handa
handa@m17n.org
reply via email to
[Prev in Thread] Current Thread [Next in Thread]