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

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

[Eli Zaretskii]

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)

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

[Kenichi Handa]

In article <E1PT77y-0008NR-Ae@fencepost.gnu.org>, Eli Zaretskii <eliz@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@m17n.org

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

[Eli Zaretskii]

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

Thank you.

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

[Eli Zaretskii]

> From: Kenichi Handa <handa@m17n.org>
> Cc: 7651@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.

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

[Kenichi Handa]

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

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

[Andreas Schwab]

Kenichi Handa <handa@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@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Kenichi Handa]

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

> Kenichi Handa <handa@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@m17n.org

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

[Kenichi Handa]

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

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

[Chong Yidong]

Kenichi Handa <handa@m17n.org> writes:

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

Done.

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

[Eli Zaretskii]

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

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

[Eli Zaretskii]

> Date: Sat, 01 Jan 2011 13:00:44 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 7651@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@gmx.de>
  To: Ken Raeburn <raeburn@raeburn.org>
  Date: Sat, 01 Jan 2011 15:20:58 +0100
  Cc: rms@gnu.org, Emacs Dev <emacs-devel@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@gnu.org Sat Jan 01 09:21:30 2011
  Return-path: <emacs-devel-bounces+eliz=gnu.org@gnu.org>
  Envelope-to: eliz@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@gnu.org>)
	  id 1PZ2Ko-0003mt-2D
	  for eliz@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@gnu.org>)
	  id 1PZ2Kq-00016f-DO
	  for eliz@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@gnu.org>)
	  id 1PZ2Kp-00016U-KE
	  for eliz@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@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@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@gmx.de>) id 1PZ2KS-0000ys-P1
	  for emacs-devel@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@gmx.de>) id 1PZ2KS-0000yf-CX
	  for emacs-devel@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@gmx.de>
  To: Ken Raeburn <raeburn@raeburn.org>
  References: <87sjxi5hko.fsf@snail.Pool>
	  <jwvr5d1lmo6.fsf-monnier+emacs@gnu.org> <87lj39y52n.fsf@snail.Pool>
	  <E1PXql5-0005hB-0s@fencepost.gnu.org> <87pqsl7wt7.fsf@snail.Pool>
	  <66798668-5808-473B-BF11-DF4DBA5464A1@raeburn.org>
  Date: Sat, 01 Jan 2011 15:20:58 +0100
  In-Reply-To: <66798668-5808-473B-BF11-DF4DBA5464A1@raeburn.org> (Ken Raeburn's
	  message of "Wed, 29 Dec 2010 23:08:09 -0500")
  Message-ID: <8739pc9039.fsf@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@gnu.org, Emacs Dev <emacs-devel@gnu.org>
  Subject: Re: Some OpenWrt port related problems
  X-BeenThere: emacs-devel@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@gnu.org?subject=unsubscribe>
  List-Archive: <http://lists.gnu.org/archive/html/emacs-devel>
  List-Post: <mailto:emacs-devel@gnu.org>
  List-Help: <mailto:emacs-devel-request@gnu.org?subject=help>
  List-Subscribe: <http://lists.gnu.org/mailman/listinfo/emacs-devel>,
	  <mailto:emacs-devel-request@gnu.org?subject=subscribe>
  Sender: emacs-devel-bounces+eliz=gnu.org@gnu.org
  Errors-To: emacs-devel-bounces+eliz=gnu.org@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@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-----
  --=-=-=--

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

[Kenichi Handa]

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

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

[Kenichi Handa]

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

> Kenichi Handa <handa@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@m17n.org

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

[Eli Zaretskii]

> From: Kenichi Handa <handa@m17n.org>
> Cc: 7651@debbugs.gnu.org
> 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.

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.

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

[Eli Zaretskii]

> From: Kenichi Handa <handa@m17n.org>
> Cc: eliz@gnu.org, 7651@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 ;-)

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

[Kenichi Handa]

In article <83fwtcprv3.fsf@gnu.org>, Eli Zaretskii <eliz@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@gmx.de>
>   To: Ken Raeburn <raeburn@raeburn.org>
>   Date: Sat, 01 Jan 2011 15:20:58 +0100
>   Cc: rms@gnu.org, Emacs Dev <emacs-devel@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@m17n.org

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

[Kenichi Handa]

In article <E1Pa0TZ-00042l-SJ@fencepost.gnu.org>, Eli Zaretskii <eliz@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@m17n.org

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

[Eli Zaretskii]

> From: Kenichi Handa <handa@m17n.org>
> Cc: 7651@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.

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

[Kenichi Handa]

In article <83oc7tkv4x.fsf@gnu.org>, Eli Zaretskii <eliz@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@m17n.org

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

[Eli Zaretskii]

> From: Kenichi Handa <handa@m17n.org>
> Cc: 7651@debbugs.gnu.org
> Date: Wed, 12 Jan 2011 15:22:14 +0900
> 
> By the way, I can't reproduce the incorrect setting of
> buffer-file-coding-system.

You mean, the one with cp1252 I reported in bug#7626?  Or the one
with EOL being undecided?  I guess the former.

> Could you "recend" the
> problematic mail, and let me know the subject line in
> another mail so that I can identify that problematic mail.

I attach one such message below (indented 2 columns).  This is an even
worse offender: the message headers clearly say that it's in
ISO-8859-1, but I still get cp1252 in the Rmail buffer.  I don't know
where that value comes from.  FWIW, my default-buffer-file-coding-system
is iso-latin-1-dos and w32-system-coding-system is cp1255.

  From emacs-devel-bounces+eliz=gnu.org@gnu.org Mon Jan 03 16:34:24 2011
  Return-path: <emacs-devel-bounces+eliz=gnu.org@gnu.org>
  Envelope-to: eliz@gnu.org
  Delivery-date: Mon, 03 Jan 2011 16:34:24 -0500
  Received: from eggs.gnu.org ([140.186.70.92]:60304)
	  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@gnu.org>)
	  id 1PZs2q-000351-I2
	  for eliz@gnu.org; Mon, 03 Jan 2011 16:34:24 -0500
  Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	  (envelope-from <emacs-devel-bounces+eliz=gnu.org@gnu.org>)
	  id 1PZs2s-0002FG-RK
	  for eliz@gnu.org; Mon, 03 Jan 2011 16:34:27 -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,RCVD_IN_DNSWL_NONE,
	  RFC_ABUSE_POST autolearn=unavailable version=3.3.1
  Received: from lists.gnu.org ([199.232.76.165]:51247)
	  by eggs.gnu.org with esmtp (Exim 4.71)
	  (envelope-from <emacs-devel-bounces+eliz=gnu.org@gnu.org>)
	  id 1PZs2s-0002FC-P5
	  for eliz@gnu.org; Mon, 03 Jan 2011 16:34:26 -0500
  Received: from localhost ([127.0.0.1]:58728 helo=lists.gnu.org)
	  by lists.gnu.org with esmtp (Exim 4.43)
	  id 1PZs2s-0007Ku-JW
	  for eliz@gnu.org; Mon, 03 Jan 2011 16:34:26 -0500
  Received: from [140.186.70.92] (port=32772 helo=eggs.gnu.org)
	  by lists.gnu.org with esmtp (Exim 4.43) id 1PZs2W-0007Kf-G9
	  for emacs-devel@gnu.org; Mon, 03 Jan 2011 16:34:05 -0500
  Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	  (envelope-from <jan.h.d@swipnet.se>) id 1PZs2V-0002An-Eb
	  for emacs-devel@gnu.org; Mon, 03 Jan 2011 16:34:04 -0500
  Received: from smtprelay-h22.telenor.se ([195.54.99.197]:44511)
	  by eggs.gnu.org with esmtp (Exim 4.71)
	  (envelope-from <jan.h.d@swipnet.se>)
	  id 1PZs2T-0002AG-TX; Mon, 03 Jan 2011 16:34:02 -0500
  Received: from ipb1.telenor.se (ipb1.telenor.se [195.54.127.164])
	  by smtprelay-h22.telenor.se (Postfix) with ESMTP id BDDEDEAD9B;
	  Mon,  3 Jan 2011 22:34:00 +0100 (CET)
  X-SENDER-IP: [85.225.45.100]
  X-LISTENER: [smtp.bredband.net]
  X-IronPort-Anti-Spam-Filtered: true
  X-IronPort-Anti-Spam-Result: AmIxAGjPIU1V4S1kPGdsb2JhbACIRJtwDAEBAQE1L7wMhUoEjiE
  X-IronPort-AV: E=Sophos;i="4.60,268,1291590000"; d="scan'208";a="163718935"
  Received: from c-642de155.25-1-64736c10.cust.bredbandsbolaget.se (HELO
	  coolsville.localdomain) ([85.225.45.100])
	  by ipb1.telenor.se with ESMTP; 03 Jan 2011 22:34:00 +0100
  Received: from [172.20.199.13] (zeplin [172.20.199.13])
	  by coolsville.localdomain (Postfix) with ESMTPSA id E262C7FA05A;
	  Mon,  3 Jan 2011 22:33:59 +0100 (CET)
  Message-ID: <4D2240C8.2060602@swipnet.se>
  Date: Mon, 03 Jan 2011 22:34:00 +0100
  From: =?ISO-8859-1?Q?Jan_Dj=E4rv?= <jan.h.d@swipnet.se>
  User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; sv-SE;
	  rv:1.9.2.13) Gecko/20101129 Thunderbird/3.1.7
  MIME-Version: 1.0
  To: Chong Yidong <cyd@stupidchicken.com>
  References: <AANLkTin-OjWynp7GOEPnSTKxf2PXH1+t6LWbmQBwCCFD@mail.gmail.com>	<4D1B27AF.7010701@swipnet.se>
	  <jwvpqskio2r.fsf-monnier+emacs@gnu.org>	<AANLkTi=Jh7pr9_w-9LfJhKBdfDwDuLYnRk5Ke6KyRRy4@mail.gmail.com>	<4D1C6E7D.2040300@swipnet.se>	<AANLkTim_habwF6AN=ncPjUey0umF22TZC_X_RJO2i845@mail.gmail.com>	<4D1D0172.8080404@swipnet.se>	<AANLkTimSLno7xk5xuM+zMM9dujyZoeofoC7vRKrpiQfp@mail.gmail.com>	<4D1DB555.5080002@swipnet.se>
	  <4D1DBD4A.6010303@swipnet.se>	<83d3oiaysj.fsf@gnu.org>
	  <4D1DD655.1040809@swipnet.se>	<83aajmaxme.fsf@gnu.org>
	  <jwv62u9hohk.fsf-monnier+emacs@gnu.org>	<AANLkTi=JN3AjvyBcAC5uTi4pnyARnUkOO8U95vDiyWvY@mail.gmail.com>	<4D1E5987.2000502@swipnet.se>
	  <jwvoc81fssl.fsf-monnier+emacs@gnu.org>	<83oc80q1k4.fsf@gnu.org>	<AANLkTinKjo8tDKMovGcpuXoHDKqJ_3ik1+fGjGua+bzN@mail.gmail.com>	<83bp40pr7m.fsf@gnu.org>
	  <4D1F73B1.3010701@swipnet.se> <87r5cvz9ms.fsf@stupidchicken.com>
  In-Reply-To: <87r5cvz9ms.fsf@stupidchicken.com>
  Content-Type: text/plain; charset=ISO-8859-1; format=flowed
  Content-Transfer-Encoding: 7bit
  X-detected-operating-system: by eggs.gnu.org: Genre and OS details not
	  recognized.
  Cc: u.s.reddy@cs.bham.ac.uk, emacs user <user.emacs@gmail.com>,
	  emacs-devel@gnu.org, monnier@iro.umontreal.ca,
	  7517@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>
  Subject: Re: bug#7517: 24.0.50; repeated crash under Mac OS X
  X-BeenThere: emacs-devel@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@gnu.org?subject=unsubscribe>
  List-Archive: <http://lists.gnu.org/archive/html/emacs-devel>
  List-Post: <mailto:emacs-devel@gnu.org>
  List-Help: <mailto:emacs-devel-request@gnu.org?subject=help>
  List-Subscribe: <http://lists.gnu.org/mailman/listinfo/emacs-devel>,
	  <mailto:emacs-devel-request@gnu.org?subject=subscribe>
  X-Mailman-Copy: yes
  Sender: emacs-devel-bounces+eliz=gnu.org@gnu.org
  Errors-To: emacs-devel-bounces+eliz=gnu.org@gnu.org
  X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2)
  X-RMAIL-ATTRIBUTES: -D------

  Done.

	  Jan D.

  Chong Yidong skrev 2011-01-02 15.02:
  > "Jan D."<jan.h.d@swipnet.se>  writes:
  >
  >> Eli Zaretskii skrev 2011-01-01 16:40:
  >>
  >>> right?
  >>>
  >>> I guess this bug report can be closed now.  Any objections?
  >>
  >> No.
  >
  > Please backport the fix to the emacs-23 branch, thanks.

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

[Eli Zaretskii]

> From: Kenichi Handa <handa@m17n.org>
> Cc: 7651@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.

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

[Kenichi Handa]

In article <83ipxuie35.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:

> You mean, the one with cp1252 I reported in bug#7626?  Or the one
> with EOL being undecided?  I guess the former.

Yes.

> I attach one such message below (indented 2 columns).  This is an even
> worse offender: the message headers clearly say that it's in
> ISO-8859-1, but I still get cp1252 in the Rmail buffer.  I don't know
> where that value comes from.  FWIW, my default-buffer-file-coding-system
> is iso-latin-1-dos and w32-system-coding-system is cp1255.

I found that rfc2047-decode-region (called while preparing
the message header) sets last-coding-system-used to
windows-1252.  That is because mm-util.el defines
mm-charset-override-alist as this:

  '((gb2312 . gbk)
    (iso-8859-1 . windows-1252)
    (iso-8859-8 . windows-1255)
    (iso-8859-9 . windows-1254))

And explains it as this:

i.e. treat iso-8859-1 as windows-1252.  windows-1252 is a
superset of iso-8859-1."

At the moment, I don't know how (or where) to fix this
problem, but at least, it seems that setting
buffer-file-coding-system to windows-1252 for iso-8859-1
message won't cause an actual problem.

---
Kenichi Handa
handa@m17n.org

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

[Eli Zaretskii]

> From: Kenichi Handa <handa@m17n.org>
> Cc: 7626@debbugs.gnu.org
> Date: Thu, 13 Jan 2011 10:21:33 +0900
> 
> I found that rfc2047-decode-region (called while preparing
> the message header) sets last-coding-system-used to
> windows-1252.  That is because mm-util.el defines
> mm-charset-override-alist as this:
> 
>   '((gb2312 . gbk)
>     (iso-8859-1 . windows-1252)
>     (iso-8859-8 . windows-1255)
>     (iso-8859-9 . windows-1254))
> 
> And explains it as this:
> 
> i.e. treat iso-8859-1 as windows-1252.  windows-1252 is a
> superset of iso-8859-1."

I guess this is because some broken mailers state Latin-N while
actually using the corresponding Windows codepage, and when the
message includes characters not in Latin-N, they are not displayed
correctly.

But even if we keep this "feature" (see below for an alternative
suggestion), I don't see a need to force this on users.  We should
have a user option to do this.  Personally, I think it should be off
by default, but if someone feels strongly about that, I won't mind
having it on by default, in which case I will customize it on my
system.

> At the moment, I don't know how (or where) to fix this
> problem, but at least, it seems that setting
> buffer-file-coding-system to windows-1252 for iso-8859-1
> message won't cause an actual problem.

It's surprising and kludgey, IMO.  A better solution would be to
decode by windows-12XX, but set last-coding-system-used to Latin-N.
That way, only if I reuse the text that is not encodable by Latin-N, I
will need to do something.  Otherwise, I get to have the cake and eat
it, too.

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

[Kenichi Handa]

In article <E1PdM2b-00011L-Cr@fencepost.gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:

> > At the moment, I don't know how (or where) to fix this
> > problem, but at least, it seems that setting
> > buffer-file-coding-system to windows-1252 for iso-8859-1
> > message won't cause an actual problem.

> It's surprising and kludgey, IMO.  A better solution would be to
> decode by windows-12XX, but set last-coding-system-used to Latin-N.
> That way, only if I reuse the text that is not encodable by Latin-N, I
> will need to do something.  Otherwise, I get to have the cake and eat
> it, too.

I don't want to modify rfc2047.el nor mm-util.el now.  So,
I've just installed a little bit inefficient workaround
which does this:

After decoding each header, if rmail-mime-coding-system is
nil, set it to a cons (CODING-SYSTEM . nil).

After decoding each body, if rmail-mime-coding-system is nil
or a cons, set it to CODING-SYSTEM.

After decoding a whole message, if rmail-mime-coding-system
is a cons (i.e. only a header part is decoded), re-decode
the header while binding mm-charset-override-alist to nil,
and set rmail-mime-coding-system to last-coding-system-used.

Set buffer-file-coding-system to rmail-mime-coding-system.

By this, encoding specified for a body always takes
precedence which I think is the right thing.

---
Kenichi Handa
handa@m17n.org

bug#7626: mm-charset-override-alist (was: bug#7626: bug#7651: 23.2.91; Rmail doesn't allow displaying text attachments conveniently)

[Reiner Steib]

On Fri, Jan 14 2011, Kenichi Handa wrote:

> Eli Zaretskii <eliz@gnu.org> writes:
>> I guess this is because some broken mailers state Latin-N while
>> actually using the corresponding Windows codepage, and when the
>> message includes characters not in Latin-N, they are not displayed
>> correctly.

Exactly.
 
>> But even if we keep this "feature" (see below for an alternative
>> suggestion), I don't see a need to force this on users.  We should
>> have a user option to do this.  Personally, I think it should be off
>> by default, but if someone feels strongly about that, I won't mind
>> having it on by default, in which case I will customize it on my
>> system.

I think `mm-charset-override-alist' should be on by default.  Before I
added (back in 2005) we frequently had complains about "why doesn't
Gnus display this article correctly?".  I don't recall any real
problems with this.

>> > At the moment, I don't know how (or where) to fix this
>> > problem, but at least, it seems that setting
>> > buffer-file-coding-system to windows-1252 for iso-8859-1
>> > message won't cause an actual problem.
>
>> It's surprising and kludgey, IMO.  A better solution would be to
>> decode by windows-12XX, but set last-coding-system-used to Latin-N.
>> That way, only if I reuse the text that is not encodable by Latin-N, I
>> will need to do something.  Otherwise, I get to have the cake and eat
>> it, too.
>
> I don't want to modify rfc2047.el nor mm-util.el now.  

Thank you.

(I don't have an opinion about what Rmail should do.)

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

bug#7626: mm-charset-override-alist (was: bug#7626: bug#7651: 23.2.91; Rmail doesn't allow displaying text attachments conveniently)

[Eli Zaretskii]

> From: Reiner Steib <reinersteib+gmane@imap.cc>
> Cc: Eli Zaretskii <eliz@gnu.org>, 7626@debbugs.gnu.org
> Reply-To: Reiner Steib <Reiner.Steib@gmx.de>
> Date: Tue, 18 Jan 2011 09:07:30 +0100
> 
> I think `mm-charset-override-alist' should be on by default.  Before I
> added (back in 2005) we frequently had complains about "why doesn't
> Gnus display this article correctly?".  I don't recall any real
> problems with this.

2005 was 6 years ago.  Perhaps things changed since then.

bug#7626: mm-charset-override-alist

[Stefan Monnier]

>> I think `mm-charset-override-alist' should be on by default.  Before I
>> added (back in 2005) we frequently had complains about "why doesn't
>> Gnus display this article correctly?".  I don't recall any real
>> problems with this.

> 2005 was 6 years ago.  Perhaps things changed since then.

AFAIK, none of the root causes for these problems have changed.


        Stefan

bug#7626: mm-charset-override-alist

[Reiner Steib]

On Tue, Jan 18 2011, Stefan Monnier wrote:

>>> I think `mm-charset-override-alist' should be on by default.  Before I
>>> added (back in 2005) we frequently had complains about "why doesn't
>>> Gnus display this article correctly?".  I don't recall any real
>>> problems with this.
>
>> 2005 was 6 years ago.  Perhaps things changed since then.
>
> AFAIK, none of the root causes for these problems have changed.

I agree.  I found around 40 articles declared as iso-8859-* which
contain #x80 (the position of the EUR sign € in windows-1252) in my
local leafnode news spool which contains mostly technical usenet
groups (comp.*, de.comp.*, de.comm.*, ...) and mailing list from
gmane.org.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

bug#7626: mm-charset-override-alist

[Eli Zaretskii]

> From: Reiner Steib <reinersteib+gmane@imap.cc>
> Cc: Eli Zaretskii <eliz@gnu.org>, 7626@debbugs.gnu.org
> Reply-To: Reiner Steib <Reiner.Steib@gmx.de>
> Date: Wed, 19 Jan 2011 22:23:55 +0100
> 
> I found around 40 articles declared as iso-8859-* which
> contain #x80 (the position of the EUR sign € in windows-1252) in my
> local leafnode news spool which contains mostly technical usenet
> groups (comp.*, de.comp.*, de.comm.*, ...) and mailing list from
> gmane.org.

40 out of how many?

Anyway, Rmail is about reading mail, not about reading news groups.
rmail-reply uses the encoding of the message replied to for setting
the encoding of the reply.  This "feature" makes me reply with a
windows-12xx encoding to someone whose sole "fault" is that she has
Latin-X characters in her name, which is RFC-2047 encoded in the From:
header.  This is ugly and unnecessary.  Emacs should not do this
unless the problematic characters are really present in the message.

I guess I will simply customize away mm-charset-override-alist, if no
one shares these concerns.

bug#7626: mm-charset-override-alist

[Stefan Monnier]

> Anyway, Rmail is about reading mail, not about reading news groups.
> rmail-reply uses the encoding of the message replied to for setting
> the encoding of the reply.

Sounds like a problem in rmail-reply, then.  E.g. what happens if the
reply includes chars that aren't covered by that coding-system?


        Stefan

bug#7626: mm-charset-override-alist

[Kenichi Handa]

In article <E1PfiZM-0005hs-Sq@fencepost.gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:

> I guess I will simply customize away mm-charset-override-alist, if no
> one shares these concerns.

I think you don't need that with the latest code.

I wrote:

> I don't want to modify rfc2047.el nor mm-util.el now.  So,
> I've just installed a little bit inefficient workaround
> which does this:

> After decoding each header, if rmail-mime-coding-system is
> nil, set it to a cons (CODING-SYSTEM . nil).

> After decoding each body, if rmail-mime-coding-system is nil
> or a cons, set it to CODING-SYSTEM.

> After decoding a whole message, if rmail-mime-coding-system
> is a cons (i.e. only a header part is decoded), re-decode
> the header while binding mm-charset-override-alist to nil,
> and set rmail-mime-coding-system to last-coding-system-used.

> Set buffer-file-coding-system to rmail-mime-coding-system.

Have you tried it?

---
Kenichi Handa
handa@m17n.org

bug#7626: mm-charset-override-alist

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Reiner Steib <Reiner.Steib@gmx.de>,  7626@debbugs.gnu.org
> Date: Wed, 19 Jan 2011 20:57:05 -0500
> 
> > rmail-reply uses the encoding of the message replied to for setting
> > the encoding of the reply.
> 
> Sounds like a problem in rmail-reply, then.

If you have a better alternative for guessing the suitable encoding of
the reply, please suggest it.  For me, it works in 99% of cases.

> E.g. what happens if the reply includes chars that aren't covered by
> that coding-system?

As usual in Emacs: when you hit "C-c C-s" or "C-c C-c", Emacs asks for
a suitable encoding, showing the unencodable characters in a pop-up
buffer.  The message is sent using the encoding you selected once you
select it (and Emacs verified that it can encode every character).

bug#7626: mm-charset-override-alist

[Eli Zaretskii]

> From: Kenichi Handa <handa@m17n.org>
> Cc: Reiner.Steib@gmx.de, 7626@debbugs.gnu.org
> Date: Thu, 20 Jan 2011 11:05:42 +0900
> 
> > After decoding each header, if rmail-mime-coding-system is
> > nil, set it to a cons (CODING-SYSTEM . nil).
> 
> > After decoding each body, if rmail-mime-coding-system is nil
> > or a cons, set it to CODING-SYSTEM.

What is CODING-SYSTEM here?

> > After decoding a whole message, if rmail-mime-coding-system
> > is a cons (i.e. only a header part is decoded), re-decode
> > the header while binding mm-charset-override-alist to nil,
> > and set rmail-mime-coding-system to last-coding-system-used.
> 
> > Set buffer-file-coding-system to rmail-mime-coding-system.
> 
> Have you tried it?

Not yet.  I'm traveling, and I'm using the 23.2.91 pretest at the
moment, where the above doesn't exist.  I will try this as soon as I
can.  Thanks.

bug#7626: mm-charset-override-alist

[Eli Zaretskii]

> From: Eli Zaretskii <eliz@gnu.org>
> Date: Wed, 19 Jan 2011 19:40:08 -0500
> Cc: 7626@debbugs.gnu.org
> Reply-To: Eli Zaretskii <eliz@gnu.org>
> 
> rmail-reply uses the encoding of the message replied to for setting
> the encoding of the reply.

Sorry, that was inaccurate and misleading.  It's not rmail-reply, it's
mail-yank-original who does that, and it only does it if the encoding
of the reply buffer is the default buffer-file-coding-system (i.e. was
not yet set in any non-trivial way).  Here's the relevant part of
mail-yank-original:

	    ;; If they yank the original text, the encoding of the
	    ;; original message is a better default than
	    ;; the default buffer-file-coding-system.
	    (and (coding-system-equal
		  (default-value 'buffer-file-coding-system)
		  buffer-file-coding-system)
		 (setq buffer-file-coding-system
		       (coding-system-change-text-conversion
			buffer-file-coding-system
			(coding-system-base
			 (with-current-buffer original
			   buffer-file-coding-system))))))

The logic behind this is that if your reply cites the original, it had
better start with the encoding of that original.

bug#7626: mm-charset-override-alist

[Kenichi Handa]

In article <E1Pfk0y-0003Pf-Hi@fencepost.gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:

> > > After decoding each header, if rmail-mime-coding-system is
> > > nil, set it to a cons (CODING-SYSTEM . nil).
> > 
> > > After decoding each body, if rmail-mime-coding-system is nil
> > > or a cons, set it to CODING-SYSTEM.

> What is CODING-SYSTEM here?

For a header part, last-coding-system-used set by
rfc2047-decode-region.  For a body part, a coding system
implied by MIME charset, or if it's not valid, whatever
Emacs detected.

---
Kenichi Handa
handa@m17n.org

bug#7626: mm-charset-override-alist

[Stefan Monnier]

>> > rmail-reply uses the encoding of the message replied to for setting
>> > the encoding of the reply.
>> Sounds like a problem in rmail-reply, then.
> If you have a better alternative for guessing the suitable encoding of
> the reply, please suggest it.  For me, it works in 99% of cases.

Using message.el ;-)

>> E.g. what happens if the reply includes chars that aren't covered by
>> that coding-system?
> As usual in Emacs: when you hit "C-c C-s" or "C-c C-c", Emacs asks for
> a suitable encoding, showing the unencodable characters in a pop-up
> buffer.  The message is sent using the encoding you selected once you
> select it (and Emacs verified that it can encode every character).

I guess that's workable.


        Stefan

bug#7626: mm-charset-override-alist

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Reiner.Steib@gmx.de,  7626@debbugs.gnu.org
> Date: Thu, 20 Jan 2011 10:32:37 -0500
> 
> > If you have a better alternative for guessing the suitable encoding of
> > the reply, please suggest it.  For me, it works in 99% of cases.
> 
> Using message.el ;-)

If someone could explain its logic in setting the encoding of a reply,
I might consider that.  I tried once to understand what it does, but
quickly got lost in a maze of twisty little passages all alike.  When
I insert the citation from the original message, the buffer's encoding
is invariably UTF-8, which is not TRT from my POV.  Maybe this gets
fixed before sending, but I got lost there.

bug#7626: mm-charset-override-alist

[Eli Zaretskii]

> From: Kenichi Handa <handa@m17n.org>
> Cc: Reiner.Steib@gmx.de, 7626@debbugs.gnu.org
> Date: Thu, 20 Jan 2011 11:05:42 +0900
> 
> > I don't want to modify rfc2047.el nor mm-util.el now.  So,
> > I've just installed a little bit inefficient workaround
> > which does this:
> 
> > After decoding each header, if rmail-mime-coding-system is
> > nil, set it to a cons (CODING-SYSTEM . nil).
> 
> > After decoding each body, if rmail-mime-coding-system is nil
> > or a cons, set it to CODING-SYSTEM.
> 
> > After decoding a whole message, if rmail-mime-coding-system
> > is a cons (i.e. only a header part is decoded), re-decode
> > the header while binding mm-charset-override-alist to nil,
> > and set rmail-mime-coding-system to last-coding-system-used.
> 
> > Set buffer-file-coding-system to rmail-mime-coding-system.
> 
> Have you tried it?

I'm using it now, since it's part of the Emacs 23.2.93 pretest.

In general, it seems to work well, but I found one message where it
didn't DTRT.  This message:

  http://lists.gnu.org/archive/html/savannah-users/2011-02/msg00003.html

is shown with buffer-file-coding-system `us-ascii', whereas I would
expect it to be UTF-8, because the From: header is in UTF-8.

(I saved the raw message as it was found in my mailbox, in case you'd
need it for analysis.)

bug#7626: mm-charset-override-alist

[Kenichi Handa]

In article <8339o2a9hq.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:

> In general, it seems to work well, but I found one message where it
> didn't DTRT.  This message:

>   http://lists.gnu.org/archive/html/savannah-users/2011-02/msg00003.html

> is shown with buffer-file-coding-system `us-ascii', whereas I would
> expect it to be UTF-8, because the From: header is in UTF-8.

> (I saved the raw message as it was found in my mailbox, in case you'd
> need it for analysis.)

Thank you.  Please send it it me.

---
Kenichi Handa
handa@m17n.org

bug#7626: mm-charset-override-alist

[Kenichi Handa]

In article <8339o0ts6k.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:
> > >   http://lists.gnu.org/archive/html/savannah-users/2011-02/msg00003.html
> > 
> > > is shown with buffer-file-coding-system `us-ascii', whereas I would
> > > expect it to be UTF-8, because the From: header is in UTF-8.
> > 
> > > (I saved the raw message as it was found in my mailbox, in case you'd
> > > need it for analysis.)
> > 
> > Thank you.  Please send it it me.

> Attached.

Thank you.  In that mail, the first part of body explicitly
specifies this:

Content-Type: text/plain; charset=US-ASCII

So, according to this algorithm:

> > After decoding each header, if rmail-mime-coding-system is
> > nil, set it to a cons (CODING-SYSTEM . nil).
> 
> > After decoding each body, if rmail-mime-coding-system is nil
> > or a cons, set it to CODING-SYSTEM.
> 
> > After decoding a whole message, if rmail-mime-coding-system
> > is a cons (i.e. only a header part is decoded), re-decode
> > the header while binding mm-charset-override-alist to nil,
> > and set rmail-mime-coding-system to last-coding-system-used.
> 
> > Set buffer-file-coding-system to rmail-mime-coding-system.

the coding system is decided as us-ascii (the second step
above overrides a coding system from header).

---
Kenichi Handa
handa@m17n.org

bug#7626: mm-charset-override-alist

[Eli Zaretskii]

> From: Kenichi Handa <handa@m17n.org>
> Cc: 7626@debbugs.gnu.org
> Date: Mon, 07 Feb 2011 09:45:33 +0900
> 
> >   http://lists.gnu.org/archive/html/savannah-users/2011-02/msg00003.html
> 
> > is shown with buffer-file-coding-system `us-ascii', whereas I would
> > expect it to be UTF-8, because the From: header is in UTF-8.
> 
> > (I saved the raw message as it was found in my mailbox, in case you'd
> > need it for analysis.)
> 
> Thank you.  Please send it it me.

Sent via private email.

bug#7626: mm-charset-override-alist

[Glenn Morris]

IIUC there were a bunch of rmail changes since this. Is this report
still relevant?

bug#7626: mm-charset-override-alist

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: Kenichi Handa <handa@m17n.org>,  7626@debbugs.gnu.org
> Date: Thu, 06 Oct 2011 20:32:11 -0400
> 
> 
> IIUC there were a bunch of rmail changes since this. Is this report
> still relevant?

Somewhere along the way, in this message:

  http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7626#56

I said that the bug could be closed.  I hope that expresses my answer
clearly enough ;-)

So I'm closing it now.

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

[Eli Zaretskii]

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