GNU bug report logs - #7651
23.2.91; Rmail doesn't allow displaying text attachments conveniently

unarchive 7651

From: Eli Zaretskii <eliz <at> gnu.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 23.2.91; Rmail doesn't allow displaying text attachments conveniently
Date: Thu, 16 Dec 2010 01:15:46 -0500

The new Rmail-MIME feature is nice, but it has some rough edges.  One
of them is that I lost an easy way of displaying many text
attachments.

Specifically, it looks like we display text attachments by default,
but only if content-disposition is "inline".  Maybe that's what the
various RFCs mandate, but why isn't there at least a button to display
the text (in the same or another buffer) if the user decides to do
that?  Previously, if I trusted the sender and the contents, I could
type `e', then decode the attachment manually, and "C-c C-c" to read
it as part of the message.  Now I can only save the attachment to a
file and visit it -- an inconvenience.  For someone who gets to review
patches, this is a serious inconvenience, especially since `v' does
not seem to work anymore in the Rmail buffer.

Also, there's something strange in the way we treat text/x-patch
attachments as text.  rmailmm.el has these 2 lines:

    ("text/.*" rmail-mime-text-handler)
    ("text/\\(x-\\)?patch" rmail-mime-bulk-handler)

which to my interpretation mean that the second line will never be
used, right?

In GNU Emacs 23.2.91.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.12.9)
 of 2010-12-11 on fencepost
configured using `configure  '--with-jpeg=no' '--with-gif=no' '--with-tiff=no''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: nil
  value of $XMODIFIERS: nil
  locale-coding-system: nil
  default enable-multibyte-characters: t

Major mode: RMAIL

Minor modes in effect:
  display-time-mode: t
  show-paren-mode: t
  savehist-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t

Recent input:
ESC O A ESC O A ESC O A ESC O A ESC O A ESC O A ESC 
O A ESC O A ESC O A ESC O A ESC O B ESC O C ESC O C 
ESC O C ESC O C ESC O C ESC O C ESC O C C-r C-w C-w 
C-w C-w C-r C-x C-x C-s C-s C-s ESC O A C-x C-x C-r 
C-r ESC O A ESC O A ESC O D ESC O D ESC O D ESC O D 
C-s C-w C-w C-w C-w C-w C-w C-s C-s C-s C-x C-x C-s 
C-s C-s ESC O q ESC O A ESC O A C-x C-_ ESC O A C-_ 
C-x b RET ESC p ESC p ESC p ESC p ESC p ESC p ESC p 
ESC p ESC p ESC p ESC p ESC p ESC p ESC p SPC SPC SPC 
SPC ESC p ESC p SPC ESC p ESC n ESC p ESC p SPC ESC 
p ESC p ESC p ESC p SPC ESC p SPC ESC p SPC ESC p SPC 
SPC ESC p ESC p ESC p ESC p SPC ESC p SPC ESC p ESC 
p ESC p ESC p SPC SPC ESC p ESC p SPC SPC ESC p ESC 
p ESC p ESC p SPC SPC ESC p SPC SPC SPC ESC p ESC p 
SPC ESC p SPC SPC SPC ESC p ESC p SPC SPC ESC p ESC 
p ESC p ESC p ESC p ESC p ESC p n d ESC p p p SPC p 
p SPC p SPC p p p p p p p SPC C-x o ESC > C-x o ESC 
x r e p o r t - e m TAB RET

Recent messages:
Making completion list...
Mark set
Mark saved where search started [9 times]
Undo!
call-interactively: End of buffer [3 times]
Showing message 1124
Showing message 1124...done
Showing message 1124
Showing message 1124...done
Mark set

Load-path shadows:
None found.

Features:
(shadow emacsbug help-mode view two-column dabbrev newcomment flyspell
ispell etags ring vc-bzr cc-mode cc-fonts cc-menus cc-cmds cc-styles
cc-align cc-engine cc-vars cc-defs multi-isearch rmailsum rmailmm
message sendmail regexp-opt ecomplete rfc822 mml easymenu mml-sec
password-cache mm-decode mm-bodies mm-encode mailcap mailabbrev
nnheader gnus-util netrc gmm-utils wid-edit mailheader canlock sha1
hex-util hashcash mail-parse rfc2231 rmail rfc2047 rfc2045 ietf-drums
time-date qp mm-util mail-prsvr mail-utils time paren cus-start
cus-load savehist saveplace tooltip ediff-hook vc-hooks
lisp-float-type mwheel x-win x-dnd font-setting tool-bar dnd fontset
image fringe lisp-mode register page menu-bar rfn-eshadow timer select
scroll-bar mldrag mouse jit-lock font-lock syntax facemenu font-core
frame cham georgian utf-8-lang misc-lang vietnamese tibetan thai
tai-viet lao korean japanese hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese case-table epa-hook
jka-cmpr-hook help simple abbrev loaddefs button minibuffer faces
cus-face files text-properties overlay md5 base64 format env
code-pages mule custom widget hashtable-print-readable backquote
make-network-process font-render-setting gtk x-toolkit x multi-tty
emacs)

From: Kenichi Handa <handa <at> m17n.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 7651 <at> debbugs.gnu.org
Subject: Re: bug#7651: 23.2.91;
	Rmail doesn't allow displaying text attachments conveniently
Date: Thu, 16 Dec 2010 16:08:17 +0900

In article <E1PT77y-0008NR-Ae <at> fencepost.gnu.org>, Eli Zaretskii <eliz <at> gnu.org> writes:

> The new Rmail-MIME feature is nice, but it has some rough edges.  One
> of them is that I lost an easy way of displaying many text
> attachments.

> Specifically, it looks like we display text attachments by default,
> but only if content-disposition is "inline".  Maybe that's what the
> various RFCs mandate, but why isn't there at least a button to display
> the text (in the same or another buffer) if the user decides to do
> that?

I noticed this problem with the original rmail-mime
behaviour too, and I'm now working on providing a convenient
way.

> Also, there's something strange in the way we treat text/x-patch
> attachments as text.  rmailmm.el has these 2 lines:

>     ("text/.*" rmail-mime-text-handler)
>     ("text/\\(x-\\)?patch" rmail-mime-bulk-handler)

> which to my interpretation mean that the second line will never be
> used, right?

I didn't change that part from the original.  And anyway,
currently rmail-mime-media-type-handlers-alist is not used
when rmail-enable-mime is t.  That's because the API of the
handler function is not usable for the new behavior, but we
should not change it at this moment.  I'm trying hard not to
change the original hevaior of M-x rmail-mime.

I hope I can commit related changes within this week.

---
Kenichi Handa
handa <at> m17n.org

From: Eli Zaretskii <eliz <at> gnu.org>
To: Kenichi Handa <handa <at> m17n.org>
Cc: 7651 <at> debbugs.gnu.org
Subject: Re: bug#7651: 23.2.91;
	Rmail doesn't allow displaying text attachments conveniently
Date: Thu, 16 Dec 2010 19:33:55 +0200

> From: Kenichi Handa <handa <at> m17n.org>
> Cc: 7651 <at> debbugs.gnu.org
> Date: Thu, 16 Dec 2010 16:08:17 +0900
> 
> I hope I can commit related changes within this week.

Thank you.

From: Eli Zaretskii <eliz <at> gnu.org>
To: Kenichi Handa <handa <at> m17n.org>
Cc: 7651 <at> debbugs.gnu.org
Subject: Re: bug#7651: 23.2.91;
	Rmail doesn't allow displaying text attachments conveniently
Date: Fri, 17 Dec 2010 17:28:52 +0200

> From: Kenichi Handa <handa <at> m17n.org>
> Cc: 7651 <at> debbugs.gnu.org
> Date: Thu, 16 Dec 2010 16:08:17 +0900
> 
> > The new Rmail-MIME feature is nice, but it has some rough edges.  One
> > of them is that I lost an easy way of displaying many text
> > attachments.
> 
> > Specifically, it looks like we display text attachments by default,
> > but only if content-disposition is "inline".  Maybe that's what the
> > various RFCs mandate, but why isn't there at least a button to display
> > the text (in the same or another buffer) if the user decides to do
> > that?

Another minor issue with rmail-mm is that the header lines it inserts
in place of the attachments do not have a newline after them, so a
typical message will end up being displayed in a buffer with no final
newline.  Not a big deal, obviously.

From: Kenichi Handa <handa <at> m17n.org>
To: Kenichi Handa <handa <at> m17n.org>
Cc: eliz <at> gnu.org, 7651 <at> debbugs.gnu.org
Subject: Re: bug#7651: 23.2.91;
	Rmail doesn't allow displaying text attachments conveniently
Date: Fri, 24 Dec 2010 13:50:48 +0900

In article <tl7vd2uyz32.fsf <at> m17n.org>, Kenichi Handa <handa <at> m17n.org> 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.

---
Kenichi Handa
handa <at> m17n.org

------------------------------------------------------------
** Rmail

** The default value of `rmail-enable-mime' is now t.  Rmail decodes
MIME contents automatically.  You can customize the variable
`rmail-enable-mime' back to `nil' to disable this automatic MIME
decoding.

** The command `rmail-mime' change the displaying of a MIME message
between decoded presentation form and raw data if `rmail-enable-mime'
is non-nil.  And, with prefix argument, it change only the displaying
of the MIME entity at point.

** The new command TAB (rmail-mime-next-item) moves point to the next
item of MIME message.

** The new command backtab (rmail-mime-previous-item) moves point to
the previous item of MIME message.

** The new command RET (rmail-mime-toggle-hidden) hide or show the
body of the MIME entity at point.

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Kenichi Handa <handa <at> m17n.org>
Cc: 7651 <at> debbugs.gnu.org
Subject: Re: bug#7651: 23.2.91;
	Rmail doesn't allow displaying text attachments conveniently
Date: Fri, 24 Dec 2010 09:17:53 +0100

Kenichi Handa <handa <at> m17n.org> writes:

> ** The new command TAB (rmail-mime-next-item) moves point to the next
> item of MIME message.

A key is not a command.

** The new command rmail-mime-next-item (bound to TAB) moves point to
the next item of MIME message.

Andreas.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

From: Kenichi Handa <handa <at> m17n.org>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: 7651 <at> debbugs.gnu.org
Subject: Re: bug#7651: 23.2.91;
	Rmail doesn't allow displaying text attachments conveniently
Date: Fri, 24 Dec 2010 20:22:50 +0900

In article <m28vzffutq.fsf <at> whitebox.home>, Andreas Schwab <schwab <at> linux-m68k.org> writes:

> Kenichi Handa <handa <at> m17n.org> writes:
> > ** The new command TAB (rmail-mime-next-item) moves point to the next
> > item of MIME message.

> A key is not a command.

> ** The new command rmail-mime-next-item (bound to TAB) moves point to
> the next item of MIME message.

Ah, I see, thank you.  Just installed fixes.

---
Kenichi Handa
handa <at> m17n.org

From: Kenichi Handa <handa <at> m17n.org>
To: Kenichi Handa <handa <at> m17n.org>
Cc: eliz <at> gnu.org, 7651 <at> debbugs.gnu.org
Subject: Re: bug#7651: 23.2.91;
	Rmail doesn't allow displaying text attachments conveniently
Date: Mon, 27 Dec 2010 20:08:55 +0900

In article <tl7hbe3ojtj.fsf <at> m17n.org>, Kenichi Handa <handa <at> m17n.org> writes:

> I've just committed several changes to improve MIME
> handling.  Attached is the relevant part of NEWS.  Rmail
> users please check the new behavior.

I've just described the new behavior in info
(doc/emacs/rmail.texi).  Could someone please fix/improve my
English?

---
Kenichi Handa
handa <at> m17n.org

---- this is the relevant part in rmail.texi ----
@cindex MIME messages (Rmail)
@vindex rmail-enable-mime
  Rmail, by default, decodes a MIME message and display the body
part(s) in a humar readable way.  If the message contains multiple
parts (entities), each part has an additional single tagline that
contains the information about depth, index, and type of the part.  It
may also contain buttons to handle the part (for saving or
image-showing).

  If you customize @code{rmail-enable-mime} to @code{nil} (the default
is @code{t}), Rmail does not show MIME decoded message until a user
explicitly requires it.

@table @kbd
@findex rmail-mime-toggle-hidden
@item @key{RET}
  Hide or show the body of a MIME entity at point.

@findex rmail-mime-next-item
@item @key{TAB}
  Move point to the next displayed item of MIME entity (part).

@findex rmail-mime-previous-item
@item @key{BackTab}
  Move point to the previous displayed item of MIME entity (part).

@findex rmail-mime
@item v
@kindex v @r{(Rmail)}
  The @kbd{v} (@code{rmail-mime}) command toggles the display of a
MIME message between the raw mode and the default mode.  In the raw
mode, the undecoded MIME data is displayed.  With a prefix argument,
it toggles the display of only an entity at point.

  But, if the variable @code{rmail-enable-mime} is @code{nil}, the
command creates a temporary buffer displaying the current MIME
message.  By default, it displays plain text and multipart messages,
and offers buttons to save attachments.
@end table

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Kenichi Handa <handa <at> m17n.org>
Cc: eliz <at> gnu.org, 7651 <at> debbugs.gnu.org
Subject: Re: bug#7651: 23.2.91;
	Rmail doesn't allow displaying text attachments conveniently
Date: Thu, 30 Dec 2010 20:39:36 +0800

Kenichi Handa <handa <at> m17n.org> writes:

> I've just described the new behavior in info
> (doc/emacs/rmail.texi).  Could someone please fix/improve my
> English?

Done.

From: Eli Zaretskii <eliz <at> gnu.org>
To: Kenichi Handa <handa <at> m17n.org>
Cc: 7651 <at> debbugs.gnu.org
Subject: Re: bug#7651: 23.2.91;
	Rmail doesn't allow displaying text attachments conveniently
Date: Sat, 01 Jan 2011 13:00:44 +0200

> From: Kenichi Handa <handa <at> m17n.org>
> Cc: eliz <at> gnu.org, 7651 <at> debbugs.gnu.org
> Date: Fri, 24 Dec 2010 13:50:48 +0900
> 
> In article <tl7vd2uyz32.fsf <at> m17n.org>, Kenichi Handa <handa <at> m17n.org> 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.

From: Eli Zaretskii <eliz <at> gnu.org>
To: handa <at> m17n.org
Cc: 7651 <at> debbugs.gnu.org
Subject: Re: bug#7651: 23.2.91;
	Rmail doesn't allow displaying text attachments conveniently
Date: Sat, 01 Jan 2011 17:26:40 +0200

> Date: Sat, 01 Jan 2011 13:00:44 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 7651 <at> debbugs.gnu.org
> 
> Thanks.  I just started using it.  It is much better now.  I have only
> a couple of minor issues to report so far:

Here's one more problem, a more serious one.  The message reproduced
below, posted today to emacs-devel, is by default displayed with no
body at all for the 1st part, like this (indentation added):

  From: David Kuehling <dvdkhlng <at> gmx.de>
  To: Ken Raeburn <raeburn <at> raeburn.org>
  Date: Sat, 01 Jan 2011 15:20:58 +0100
  Cc: rms <at> gnu.org, Emacs Dev <emacs-devel <at> gnu.org>
  Subject: Re: Some OpenWrt port related problems

  [1:multipart/signed]
  [2:application/pgp-signature file:noname (189B)]

I guess we need to handle parts with no Content-Type at all?

Here's the original message, copied from the RMAIL buffer after
toggling the display with `v' (again, indentation added):

  From emacs-devel-bounces+eliz=gnu.org <at> gnu.org Sat Jan 01 09:21:30 2011
  Return-path: <emacs-devel-bounces+eliz=gnu.org <at> gnu.org>
  Envelope-to: eliz <at> gnu.org
  Delivery-date: Sat, 01 Jan 2011 09:21:30 -0500
  Received: from eggs.gnu.org ([140.186.70.92]:50257)
	  by fencepost.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32)
	  (Exim 4.69)
	  (envelope-from <emacs-devel-bounces+eliz=gnu.org <at> gnu.org>)
	  id 1PZ2Ko-0003mt-2D
	  for eliz <at> gnu.org; Sat, 01 Jan 2011 09:21:30 -0500
  Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	  (envelope-from <emacs-devel-bounces+eliz=gnu.org <at> gnu.org>)
	  id 1PZ2Kq-00016f-DO
	  for eliz <at> gnu.org; Sat, 01 Jan 2011 09:21:33 -0500
  X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on eggs.gnu.org
  X-Spam-Level: 
  X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,
	  RCVD_IN_DNSWL_NONE,T_MIME_NO_TEXT autolearn=unavailable version=3.3.1
  Received: from lists.gnu.org ([199.232.76.165]:57125)
	  by eggs.gnu.org with esmtp (Exim 4.71)
	  (envelope-from <emacs-devel-bounces+eliz=gnu.org <at> gnu.org>)
	  id 1PZ2Kp-00016U-KE
	  for eliz <at> gnu.org; Sat, 01 Jan 2011 09:21:31 -0500
  Received: from localhost ([127.0.0.1]:54155 helo=lists.gnu.org)
	  by lists.gnu.org with esmtp (Exim 4.43)
	  id 1PZ2Kp-0005ny-FW
	  for eliz <at> gnu.org; Sat, 01 Jan 2011 09:21:31 -0500
  Received: from [140.186.70.92] (port=33845 helo=eggs.gnu.org)
	  by lists.gnu.org with esmtp (Exim 4.43) id 1PZ2KU-0005ns-Ld
	  for emacs-devel <at> gnu.org; Sat, 01 Jan 2011 09:21:11 -0500
  Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	  (envelope-from <dvdkhlng <at> gmx.de>) id 1PZ2KS-0000ys-P1
	  for emacs-devel <at> gnu.org; Sat, 01 Jan 2011 09:21:10 -0500
  Received: from mailout-de.gmx.net ([213.165.64.23]:56759 helo=mail.gmx.net)
	  by eggs.gnu.org with smtp (Exim 4.71)
	  (envelope-from <dvdkhlng <at> gmx.de>) id 1PZ2KS-0000yf-CX
	  for emacs-devel <at> gnu.org; Sat, 01 Jan 2011 09:21:08 -0500
  Received: (qmail invoked by alias); 01 Jan 2011 14:21:05 -0000
  Received: from g225041162.adsl.alicedsl.de (EHLO snail.gmx.de) [92.225.41.162]
	  by mail.gmx.net (mp045) with SMTP; 01 Jan 2011 15:21:05 +0100
  X-Authenticated: #4121607
  X-Provags-ID: V01U2FsdGVkX1//MpsRJHX/GjPLea+HpHz6pI07dsTdZCK9rl/RiR
	  Tae4tRtlRKjlu2
  From: David Kuehling <dvdkhlng <at> gmx.de>
  To: Ken Raeburn <raeburn <at> raeburn.org>
  References: <87sjxi5hko.fsf <at> snail.Pool>
	  <jwvr5d1lmo6.fsf-monnier+emacs <at> gnu.org> <87lj39y52n.fsf <at> snail.Pool>
	  <E1PXql5-0005hB-0s <at> fencepost.gnu.org> <87pqsl7wt7.fsf <at> snail.Pool>
	  <66798668-5808-473B-BF11-DF4DBA5464A1 <at> raeburn.org>
  Date: Sat, 01 Jan 2011 15:20:58 +0100
  In-Reply-To: <66798668-5808-473B-BF11-DF4DBA5464A1 <at> raeburn.org> (Ken Raeburn's
	  message of "Wed, 29 Dec 2010 23:08:09 -0500")
  Message-ID: <8739pc9039.fsf <at> snail.Pool>
  User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)
  MIME-Version: 1.0
  Content-Type: multipart/signed; boundary="=-=-=";
	  micalg=pgp-sha1; protocol="application/pgp-signature"
  X-Y-GMX-Trusted: 0
  X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3)
  Cc: rms <at> gnu.org, Emacs Dev <emacs-devel <at> gnu.org>
  Subject: Re: Some OpenWrt port related problems
  X-BeenThere: emacs-devel <at> gnu.org
  X-Mailman-Version: 2.1.5
  Precedence: list
  List-Id: "Emacs development discussions." <emacs-devel.gnu.org>
  List-Unsubscribe: <http://lists.gnu.org/mailman/listinfo/emacs-devel>,
	  <mailto:emacs-devel-request <at> gnu.org?subject=unsubscribe>
  List-Archive: <http://lists.gnu.org/archive/html/emacs-devel>
  List-Post: <mailto:emacs-devel <at> gnu.org>
  List-Help: <mailto:emacs-devel-request <at> gnu.org?subject=help>
  List-Subscribe: <http://lists.gnu.org/mailman/listinfo/emacs-devel>,
	  <mailto:emacs-devel-request <at> gnu.org?subject=subscribe>
  Sender: emacs-devel-bounces+eliz=gnu.org <at> gnu.org
  Errors-To: emacs-devel-bounces+eliz=gnu.org <at> gnu.org
  X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2)
  X-RMAIL-ATTRIBUTES: --------

  --=-=-=
  Content-Transfer-Encoding: quoted-printable

  >>>>> "Ken" =3D=3D Ken Raeburn <raeburn <at> raeburn.org> writes:

  > On Dec 29, 2010, at 04:28, David Kuehling wrote:

  >> I could dump Emacs in the target system, from a wrapper script, when
  >> launched for the first time.  But last time I tried that it failed
  >> with insufficient memory (32Mb RAM, no swap), so I'm going without
  >> dumping for now.

  > It sounds like running Emacs on such a system is going to be pretty
  > marginal in any case, but do you recall what part of it failed?
  > Finding the doc strings?  The actual dumping?

  Ok, just recompiled emacs with dumping support, and running

    $ emacs -Q --batch --eval \
      '(dump-emacs "./demacs" "/usr/bin/emacs")'

  on the NanoNote gave me:

    [..]
    Loading ediff-hook...
    Finding pointers to doc strings...
    Finding pointers to doc strings...done
    emacs: Can't allocate buffer for /usr/bin/emacs

  So it wants to pull a full copy of the emacs binary into memory?
  This problem I can workaround by changing the Linux overcommit setting,
  but then dumping fails with another problem:

    $ echo "1" > /proc/sys/vm/overcommit_memory=20
    $ emacs -Q --batch --eval \
       '(dump-emacs "./demacs" "/usr/bin/emacs")'

    [..]
    Finding pointers to doc strings...
    Finding pointers to doc strings...done
    emacs: Program segment above .bss in /usr/bin/emacs

  So what's that supposed to mean?=20=20

  cheers,

  David
  =2D-=20
  GnuPG public key: http://user.cs.tu-berlin.de/~dvdkhlng/dk.gpg
  Fingerprint: B17A DC95 D293 657B 4205  D016 7DEF 5323 C174 7D40

  --=-=-=
  Content-Type: application/pgp-signature

  -----BEGIN PGP SIGNATURE-----
  Version: GnuPG v1.4.10 (GNU/Linux)

  iD8DBQFNHzhLfe9TI8F0fUARAhyyAJ99DqcDST7T2KZEGeVc4zPusaHEQQCeM1wi
  xMZrhKQbr3HKWCBWKQGiI4o=
  =YpG9
  -----END PGP SIGNATURE-----
  --=-=-=--

From: Kenichi Handa <handa <at> m17n.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 7651 <at> debbugs.gnu.org
Subject: Re: 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 <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

From: Kenichi Handa <handa <at> m17n.org>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: eliz <at> gnu.org, 7651 <at> debbugs.gnu.org
Subject: Re: bug#7651: 23.2.91;
	Rmail doesn't allow displaying text attachments conveniently
Date: Tue, 04 Jan 2011 14:36:43 +0900

In article <87vd2ba0zb.fsf <at> stupidchicken.com>, Chong Yidong <cyd <at> stupidchicken.com> writes:

> Kenichi Handa <handa <at> m17n.org> writes:
> > I've just described the new behavior in info
> > (doc/emacs/rmail.texi).  Could someone please fix/improve my
> > English?

> Done.

Thank you.  But, this senetence will be misunderstood:

If the message contains multiple
parts (@acronym{MIME} entities), each part is represented by a tagline
in the Rmail buffer.  

Actually, a text/plain part is shown both with a tagline and
the decoded body.  Does "represented" imply that?

And, this is not accurate.

@findex rmail-mime-next-item
@item @key{TAB}
Move point to the next @acronym{MIME} part
(@code{rmail-mime-next-item}).

It actually moves point to the next displayed items; header,
tagline, buttons in tagline, or body.  It moves point to the
next part only if there's no more displayed item in the
current part.

---
Kenichi Handa
handa <at> m17n.org

From: Eli Zaretskii <eliz <at> gnu.org>
To: Kenichi Handa <handa <at> m17n.org>
Cc: 7651 <at> debbugs.gnu.org
Subject: Re: bug#7651: 23.2.91;
	Rmail doesn't allow displaying text attachments conveniently
Date: Tue, 04 Jan 2011 01:34:33 -0500

> From: Kenichi Handa <handa <at> m17n.org>
> Cc: 7651 <at> debbugs.gnu.org
> Date: Tue, 04 Jan 2011 14:01:11 +0900
> 
> 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.

But IMO it's confusingly inconsistent, so I think we should have a
toggle button there as well, when we don't show the body by default.

Thanks.

From: Eli Zaretskii <eliz <at> gnu.org>
To: Kenichi Handa <handa <at> m17n.org>
Cc: cyd <at> stupidchicken.com, 7651 <at> debbugs.gnu.org
Subject: Re: bug#7651: 23.2.91;
	Rmail doesn't allow displaying text attachments conveniently
Date: Tue, 04 Jan 2011 01:35:28 -0500

> From: Kenichi Handa <handa <at> m17n.org>
> Cc: eliz <at> gnu.org, 7651 <at> debbugs.gnu.org
> Date: Tue, 04 Jan 2011 14:36:43 +0900
> 
> And, this is not accurate.
> 
> @findex rmail-mime-next-item
> @item @key{TAB}
> Move point to the next @acronym{MIME} part
> (@code{rmail-mime-next-item}).

Looks like Chong expected the same as I did ;-)

From: Kenichi Handa <handa <at> m17n.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 7651 <at> debbugs.gnu.org
Subject: Re: bug#7651: 23.2.91;
	Rmail doesn't allow displaying text attachments conveniently
Date: Tue, 04 Jan 2011 16:16:31 +0900

In article <83fwtcprv3.fsf <at> gnu.org>, Eli Zaretskii <eliz <at> gnu.org> writes:

> Here's one more problem, a more serious one.  The message reproduced
> below, posted today to emacs-devel, is by default displayed with no
> body at all for the 1st part, like this (indentation added):

>   From: David Kuehling <dvdkhlng <at> gmx.de>
>   To: Ken Raeburn <raeburn <at> raeburn.org>
>   Date: Sat, 01 Jan 2011 15:20:58 +0100
>   Cc: rms <at> gnu.org, Emacs Dev <emacs-devel <at> gnu.org>
>   Subject: Re: Some OpenWrt port related problems

>   [1:multipart/signed]
>   [2:application/pgp-signature file:noname (189B)]

> I guess we need to handle parts with no Content-Type at all?

Sure.  I've just installed a fix.  In the above message, the
first part incorrectly inherited the default type as
"multipart/signed".  It should be "text/plain".

And the second part is surely "application/pgp-signature"
which current rmailmm doesn't know how to handle, but I made
the body shown as a text by typing RET.

---
Kenichi Handa
handa <at> m17n.org

From: Kenichi Handa <handa <at> m17n.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 7651 <at> debbugs.gnu.org
Subject: Re: bug#7651: 23.2.91;
	Rmail doesn't allow displaying text attachments conveniently
Date: Fri, 07 Jan 2011 16:13:11 +0900

In article <E1Pa0TZ-00042l-SJ <at> fencepost.gnu.org>, Eli Zaretskii <eliz <at> gnu.org> writes:

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

> But IMO it's confusingly inconsistent, so I think we should have a
> toggle button there as well, when we don't show the body by default.

As we can toggle all entities, to be consistent, we must
have toggle buttons on all entities.  But, I think it
results in a little bit annoying display.  So, how about
making each content-type string (e.g. "text/plain",
"image/png" in tagline) a button instead of having "Toggle
show/hide" button?

---
Kenichi Handa
handa <at> m17n.org

From: Eli Zaretskii <eliz <at> gnu.org>
To: Kenichi Handa <handa <at> m17n.org>
Cc: 7651 <at> debbugs.gnu.org
Subject: Re: bug#7651: 23.2.91;
	Rmail doesn't allow displaying text attachments conveniently
Date: Fri, 07 Jan 2011 09:53:02 +0200

> From: Kenichi Handa <handa <at> m17n.org>
> Cc: 7651 <at> debbugs.gnu.org
> Date: Fri, 07 Jan 2011 16:13:11 +0900
> 
> As we can toggle all entities, to be consistent, we must
> have toggle buttons on all entities.  But, I think it
> results in a little bit annoying display.  So, how about
> making each content-type string (e.g. "text/plain",
> "image/png" in tagline) a button instead of having "Toggle
> show/hide" button?

That would be okay, too, but since those buttons' visual appearance
has no cue to the fact that they are buttons, we should either change
their visual appearance, or maybe add some textual hint, like
"[1:text/plain (RET to show/hide)]".

I also don't think adding a "Toggle show/hide" button would make the
display annoying.

From: Kenichi Handa <handa <at> m17n.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 7651 <at> debbugs.gnu.org
Subject: Re: bug#7651: 23.2.91;
	Rmail doesn't allow displaying text attachments conveniently
Date: Wed, 12 Jan 2011 15:22:14 +0900

In article <83oc7tkv4x.fsf <at> gnu.org>, Eli Zaretskii <eliz <at> gnu.org> writes:
> > As we can toggle all entities, to be consistent, we must
> > have toggle buttons on all entities.  But, I think it
> > results in a little bit annoying display.  So, how about
> > making each content-type string (e.g. "text/plain",
> > "image/png" in tagline) a button instead of having "Toggle
> > show/hide" button?

> That would be okay, too, but since those buttons' visual appearance
> has no cue to the fact that they are buttons, we should either change
> their visual appearance, or maybe add some textual hint, like
> "[1:text/plain (RET to show/hide)]".

I've just committed several changes.  In it, I made the
tagline something like this (~~~~ indicate underlined part):

[1:text/plain Hide]
              ~~~~
[2:image/png Show Save:temp.png (XXkB)]
             ~~~~      ~~~~~~~~

and made the button label itself toggles between "Hide" and
"Show".

Another change is to bind tab and backtab simply to
forward-button and backward-button respectively because all
taglines has at least Hide or Show button now.

Please try this version for a while.  I'll update NEWS and
info when it is found that this version is good enough for
the next release.

By the way, I can't reproduce the incorrect setting of
buffer-file-coding-system.  Could you "recend" the
problematic mail, and let me know the subject line in
another mail so that I can identify that problematic mail.

---
Kenichi Handa
handa <at> m17n.org

From: Eli Zaretskii <eliz <at> gnu.org>
To: Kenichi Handa <handa <at> m17n.org>
Cc: 7651 <at> debbugs.gnu.org
Subject: Re: bug#7651: 23.2.91;
	Rmail doesn't allow displaying text attachments conveniently
Date: Wed, 12 Jan 2011 12:58:21 +0200

> From: Kenichi Handa <handa <at> m17n.org>
> Cc: 7651 <at> debbugs.gnu.org
> Date: Wed, 12 Jan 2011 15:22:14 +0900
> 
> I've just committed several changes.  In it, I made the
> tagline something like this (~~~~ indicate underlined part):
> 
> [1:text/plain Hide]
>               ~~~~
> [2:image/png Show Save:temp.png (XXkB)]
>              ~~~~      ~~~~~~~~
> 
> and made the button label itself toggles between "Hide" and
> "Show".
> 
> Another change is to bind tab and backtab simply to
> forward-button and backward-button respectively because all
> taglines has at least Hide or Show button now.
> 
> Please try this version for a while.  I'll update NEWS and
> info when it is found that this version is good enough for
> the next release.

Thanks, will do.

From: Eli Zaretskii <eliz <at> gnu.org>
To: 7651-done <at> debbugs.gnu.org
Subject: 23.2.91; Rmail doesn't allow displaying text attachments conveniently
Date: Wed, 19 Oct 2011 09:56:45 +0200

This bug was fixed quite some time ago, it's time to close it.

GNU bug report logs - #7651 23.2.91; Rmail doesn't allow displaying text attachments conveniently

GNU bug report logs - #7651
23.2.91; Rmail doesn't allow displaying text attachments conveniently