GNU bug report logs -
#7651
23.2.91; Rmail doesn't allow displaying text attachments conveniently
Previous Next
Reported by: Eli Zaretskii <eliz <at> gnu.org>
Date: Thu, 16 Dec 2010 06:10:02 UTC
Severity: normal
Fixed in version 23.2.91
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
In article <83vd28q46b.fsf <at> gnu.org>, Eli Zaretskii <eliz <at> 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 <at> m17n.org
This bug report was last modified 13 years and 223 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.