* bug#7651: 23.2.91; Rmail doesn't allow displaying text attachments conveniently @ 2010-12-16 6:15 Eli Zaretskii 2010-12-16 7:08 ` Kenichi Handa 2011-10-19 7:56 ` Eli Zaretskii 0 siblings, 2 replies; 44+ messages in thread From: Eli Zaretskii @ 2010-12-16 6:15 UTC (permalink / raw) To: 7651 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) ^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#7651: 23.2.91; Rmail doesn't allow displaying text attachments conveniently 2010-12-16 6:15 bug#7651: 23.2.91; Rmail doesn't allow displaying text attachments conveniently Eli Zaretskii @ 2010-12-16 7:08 ` Kenichi Handa 2010-12-16 17:33 ` Eli Zaretskii ` (2 more replies) 2011-10-19 7:56 ` Eli Zaretskii 1 sibling, 3 replies; 44+ messages in thread From: Kenichi Handa @ 2010-12-16 7:08 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 7651 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#7651: 23.2.91; Rmail doesn't allow displaying text attachments conveniently 2010-12-16 7:08 ` Kenichi Handa @ 2010-12-16 17:33 ` Eli Zaretskii 2010-12-17 15:28 ` Eli Zaretskii 2010-12-24 4:50 ` Kenichi Handa 2 siblings, 0 replies; 44+ messages in thread From: Eli Zaretskii @ 2010-12-16 17:33 UTC (permalink / raw) To: Kenichi Handa; +Cc: 7651 > 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. ^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#7651: 23.2.91; Rmail doesn't allow displaying text attachments conveniently 2010-12-16 7:08 ` Kenichi Handa 2010-12-16 17:33 ` Eli Zaretskii @ 2010-12-17 15:28 ` Eli Zaretskii 2010-12-24 4:50 ` Kenichi Handa 2 siblings, 0 replies; 44+ messages in thread From: Eli Zaretskii @ 2010-12-17 15:28 UTC (permalink / raw) To: Kenichi Handa; +Cc: 7651 > 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. ^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#7651: 23.2.91; Rmail doesn't allow displaying text attachments conveniently 2010-12-16 7:08 ` Kenichi Handa 2010-12-16 17:33 ` Eli Zaretskii 2010-12-17 15:28 ` Eli Zaretskii @ 2010-12-24 4:50 ` Kenichi Handa 2010-12-24 8:17 ` Andreas Schwab ` (2 more replies) 2 siblings, 3 replies; 44+ messages in thread From: Kenichi Handa @ 2010-12-24 4:50 UTC (permalink / raw) To: Kenichi Handa; +Cc: 7651 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. ^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#7651: 23.2.91; Rmail doesn't allow displaying text attachments conveniently 2010-12-24 4:50 ` Kenichi Handa @ 2010-12-24 8:17 ` Andreas Schwab 2010-12-24 11:22 ` Kenichi Handa 2010-12-27 11:08 ` Kenichi Handa 2011-01-01 11:00 ` Eli Zaretskii 2 siblings, 1 reply; 44+ messages in thread From: Andreas Schwab @ 2010-12-24 8:17 UTC (permalink / raw) To: Kenichi Handa; +Cc: 7651 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." ^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#7651: 23.2.91; Rmail doesn't allow displaying text attachments conveniently 2010-12-24 8:17 ` Andreas Schwab @ 2010-12-24 11:22 ` Kenichi Handa 0 siblings, 0 replies; 44+ messages in thread From: Kenichi Handa @ 2010-12-24 11:22 UTC (permalink / raw) To: Andreas Schwab; +Cc: 7651 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#7651: 23.2.91; Rmail doesn't allow displaying text attachments conveniently 2010-12-24 4:50 ` Kenichi Handa 2010-12-24 8:17 ` Andreas Schwab @ 2010-12-27 11:08 ` Kenichi Handa 2010-12-30 12:39 ` Chong Yidong 2011-01-01 11:00 ` Eli Zaretskii 2 siblings, 1 reply; 44+ messages in thread From: Kenichi Handa @ 2010-12-27 11:08 UTC (permalink / raw) To: Kenichi Handa; +Cc: 7651 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#7651: 23.2.91; Rmail doesn't allow displaying text attachments conveniently 2010-12-27 11:08 ` Kenichi Handa @ 2010-12-30 12:39 ` Chong Yidong 2011-01-04 5:36 ` Kenichi Handa 0 siblings, 1 reply; 44+ messages in thread From: Chong Yidong @ 2010-12-30 12:39 UTC (permalink / raw) To: Kenichi Handa; +Cc: 7651 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. ^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#7651: 23.2.91; Rmail doesn't allow displaying text attachments conveniently 2010-12-30 12:39 ` Chong Yidong @ 2011-01-04 5:36 ` Kenichi Handa 2011-01-04 6:35 ` Eli Zaretskii 0 siblings, 1 reply; 44+ messages in thread From: Kenichi Handa @ 2011-01-04 5:36 UTC (permalink / raw) To: Chong Yidong; +Cc: 7651 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#7651: 23.2.91; Rmail doesn't allow displaying text attachments conveniently 2011-01-04 5:36 ` Kenichi Handa @ 2011-01-04 6:35 ` Eli Zaretskii 0 siblings, 0 replies; 44+ messages in thread From: Eli Zaretskii @ 2011-01-04 6:35 UTC (permalink / raw) To: Kenichi Handa; +Cc: cyd, 7651 > 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 ;-) ^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#7651: 23.2.91; Rmail doesn't allow displaying text attachments conveniently 2010-12-24 4:50 ` Kenichi Handa 2010-12-24 8:17 ` Andreas Schwab 2010-12-27 11:08 ` Kenichi Handa @ 2011-01-01 11:00 ` Eli Zaretskii 2011-01-01 15:26 ` Eli Zaretskii 2011-01-04 5:01 ` Kenichi Handa 2 siblings, 2 replies; 44+ messages in thread From: Eli Zaretskii @ 2011-01-01 11:00 UTC (permalink / raw) To: Kenichi Handa; +Cc: 7651 > 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. ^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#7651: 23.2.91; Rmail doesn't allow displaying text attachments conveniently 2011-01-01 11:00 ` Eli Zaretskii @ 2011-01-01 15:26 ` Eli Zaretskii 2011-01-04 7:16 ` Kenichi Handa 2011-01-04 5:01 ` Kenichi Handa 1 sibling, 1 reply; 44+ messages in thread From: Eli Zaretskii @ 2011-01-01 15:26 UTC (permalink / raw) To: handa; +Cc: 7651 > 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----- --=-=-=-- ^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#7651: 23.2.91; Rmail doesn't allow displaying text attachments conveniently 2011-01-01 15:26 ` Eli Zaretskii @ 2011-01-04 7:16 ` Kenichi Handa 0 siblings, 0 replies; 44+ messages in thread From: Kenichi Handa @ 2011-01-04 7:16 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 7651 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#7651: 23.2.91; Rmail doesn't allow displaying text attachments conveniently 2011-01-01 11:00 ` Eli Zaretskii 2011-01-01 15:26 ` Eli Zaretskii @ 2011-01-04 5:01 ` Kenichi Handa 2011-01-04 6:34 ` Eli Zaretskii 1 sibling, 1 reply; 44+ messages in thread From: Kenichi Handa @ 2011-01-04 5:01 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 7651 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#7651: 23.2.91; Rmail doesn't allow displaying text attachments conveniently 2011-01-04 5:01 ` Kenichi Handa @ 2011-01-04 6:34 ` Eli Zaretskii 2011-01-07 7:13 ` Kenichi Handa 0 siblings, 1 reply; 44+ messages in thread From: Eli Zaretskii @ 2011-01-04 6:34 UTC (permalink / raw) To: Kenichi Handa; +Cc: 7651 > 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. ^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#7651: 23.2.91; Rmail doesn't allow displaying text attachments conveniently 2011-01-04 6:34 ` Eli Zaretskii @ 2011-01-07 7:13 ` Kenichi Handa 2011-01-07 7:53 ` Eli Zaretskii 0 siblings, 1 reply; 44+ messages in thread From: Kenichi Handa @ 2011-01-07 7:13 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 7651 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#7651: 23.2.91; Rmail doesn't allow displaying text attachments conveniently 2011-01-07 7:13 ` Kenichi Handa @ 2011-01-07 7:53 ` Eli Zaretskii 2011-01-12 6:22 ` Kenichi Handa 0 siblings, 1 reply; 44+ messages in thread From: Eli Zaretskii @ 2011-01-07 7:53 UTC (permalink / raw) To: Kenichi Handa; +Cc: 7651 > 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. ^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#7651: 23.2.91; Rmail doesn't allow displaying text attachments conveniently 2011-01-07 7:53 ` Eli Zaretskii @ 2011-01-12 6:22 ` Kenichi Handa 2011-01-12 10:57 ` bug#7626: " Eli Zaretskii 2011-01-12 10:58 ` bug#7651: 23.2.91; Rmail doesn't allow displaying text attachments conveniently Eli Zaretskii 0 siblings, 2 replies; 44+ messages in thread From: Kenichi Handa @ 2011-01-12 6:22 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 7651 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#7626: bug#7651: 23.2.91; Rmail doesn't allow displaying text attachments conveniently 2011-01-12 6:22 ` Kenichi Handa @ 2011-01-12 10:57 ` Eli Zaretskii 2011-01-13 1:21 ` Kenichi Handa 2011-01-12 10:58 ` bug#7651: 23.2.91; Rmail doesn't allow displaying text attachments conveniently Eli Zaretskii 1 sibling, 1 reply; 44+ messages in thread From: Eli Zaretskii @ 2011-01-12 10:57 UTC (permalink / raw) To: Kenichi Handa; +Cc: 7626 > 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. ^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#7626: bug#7651: 23.2.91; Rmail doesn't allow displaying text attachments conveniently 2011-01-12 10:57 ` bug#7626: " Eli Zaretskii @ 2011-01-13 1:21 ` Kenichi Handa 2011-01-13 12:12 ` Eli Zaretskii 0 siblings, 1 reply; 44+ messages in thread From: Kenichi Handa @ 2011-01-13 1:21 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 7626 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#7626: bug#7651: 23.2.91; Rmail doesn't allow displaying text attachments conveniently 2011-01-13 1:21 ` Kenichi Handa @ 2011-01-13 12:12 ` Eli Zaretskii 2011-01-14 4:23 ` Kenichi Handa 0 siblings, 1 reply; 44+ messages in thread From: Eli Zaretskii @ 2011-01-13 12:12 UTC (permalink / raw) To: Kenichi Handa; +Cc: 7626 > 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. ^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#7626: bug#7651: 23.2.91; Rmail doesn't allow displaying text attachments conveniently 2011-01-13 12:12 ` Eli Zaretskii @ 2011-01-14 4:23 ` Kenichi Handa 2011-01-18 8:07 ` bug#7626: mm-charset-override-alist (was: bug#7626: bug#7651: 23.2.91; Rmail doesn't allow displaying text attachments conveniently) Reiner Steib 0 siblings, 1 reply; 44+ messages in thread From: Kenichi Handa @ 2011-01-14 4:23 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 7626 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#7626: mm-charset-override-alist (was: bug#7626: bug#7651: 23.2.91; Rmail doesn't allow displaying text attachments conveniently) 2011-01-14 4:23 ` Kenichi Handa @ 2011-01-18 8:07 ` Reiner Steib 2011-01-18 15:10 ` Eli Zaretskii 0 siblings, 1 reply; 44+ messages in thread From: Reiner Steib @ 2011-01-18 8:07 UTC (permalink / raw) To: Kenichi Handa; +Cc: 7626 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/ ^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#7626: mm-charset-override-alist (was: bug#7626: bug#7651: 23.2.91; Rmail doesn't allow displaying text attachments conveniently) 2011-01-18 8:07 ` bug#7626: mm-charset-override-alist (was: bug#7626: bug#7651: 23.2.91; Rmail doesn't allow displaying text attachments conveniently) Reiner Steib @ 2011-01-18 15:10 ` Eli Zaretskii 2011-01-18 18:00 ` bug#7626: mm-charset-override-alist Stefan Monnier 0 siblings, 1 reply; 44+ messages in thread From: Eli Zaretskii @ 2011-01-18 15:10 UTC (permalink / raw) To: Reiner Steib; +Cc: 7626 > 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. ^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#7626: mm-charset-override-alist 2011-01-18 15:10 ` Eli Zaretskii @ 2011-01-18 18:00 ` Stefan Monnier 2011-01-19 21:23 ` Reiner Steib 0 siblings, 1 reply; 44+ messages in thread From: Stefan Monnier @ 2011-01-18 18:00 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 7626, Reiner Steib >> 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#7626: mm-charset-override-alist 2011-01-18 18:00 ` bug#7626: mm-charset-override-alist Stefan Monnier @ 2011-01-19 21:23 ` Reiner Steib 2011-01-20 0:40 ` Eli Zaretskii 0 siblings, 1 reply; 44+ messages in thread From: Reiner Steib @ 2011-01-19 21:23 UTC (permalink / raw) To: Stefan Monnier; +Cc: 7626 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/ ^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#7626: mm-charset-override-alist 2011-01-19 21:23 ` Reiner Steib @ 2011-01-20 0:40 ` Eli Zaretskii 2011-01-20 1:57 ` Stefan Monnier ` (2 more replies) 0 siblings, 3 replies; 44+ messages in thread From: Eli Zaretskii @ 2011-01-20 0:40 UTC (permalink / raw) To: Reiner Steib; +Cc: 7626 > 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. ^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#7626: mm-charset-override-alist 2011-01-20 0:40 ` Eli Zaretskii @ 2011-01-20 1:57 ` Stefan Monnier 2011-01-20 2:08 ` Eli Zaretskii 2011-01-20 2:05 ` Kenichi Handa 2011-01-20 2:27 ` Eli Zaretskii 2 siblings, 1 reply; 44+ messages in thread From: Stefan Monnier @ 2011-01-20 1:57 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 7626, Reiner Steib > 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#7626: mm-charset-override-alist 2011-01-20 1:57 ` Stefan Monnier @ 2011-01-20 2:08 ` Eli Zaretskii 2011-01-20 15:32 ` Stefan Monnier 0 siblings, 1 reply; 44+ messages in thread From: Eli Zaretskii @ 2011-01-20 2:08 UTC (permalink / raw) To: Stefan Monnier; +Cc: 7626, Reiner.Steib > 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). ^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#7626: mm-charset-override-alist 2011-01-20 2:08 ` Eli Zaretskii @ 2011-01-20 15:32 ` Stefan Monnier 2011-01-20 15:37 ` Eli Zaretskii 0 siblings, 1 reply; 44+ messages in thread From: Stefan Monnier @ 2011-01-20 15:32 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 7626, Reiner.Steib >> > 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#7626: mm-charset-override-alist 2011-01-20 15:32 ` Stefan Monnier @ 2011-01-20 15:37 ` Eli Zaretskii 0 siblings, 0 replies; 44+ messages in thread From: Eli Zaretskii @ 2011-01-20 15:37 UTC (permalink / raw) To: Stefan Monnier; +Cc: 7626, Reiner.Steib > 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. ^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#7626: mm-charset-override-alist 2011-01-20 0:40 ` Eli Zaretskii 2011-01-20 1:57 ` Stefan Monnier @ 2011-01-20 2:05 ` Kenichi Handa 2011-01-20 2:12 ` Eli Zaretskii 2011-02-05 13:36 ` Eli Zaretskii 2011-01-20 2:27 ` Eli Zaretskii 2 siblings, 2 replies; 44+ messages in thread From: Kenichi Handa @ 2011-01-20 2:05 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 7626, Reiner.Steib 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#7626: mm-charset-override-alist 2011-01-20 2:05 ` Kenichi Handa @ 2011-01-20 2:12 ` Eli Zaretskii 2011-01-20 3:51 ` Kenichi Handa 2011-02-05 13:36 ` Eli Zaretskii 1 sibling, 1 reply; 44+ messages in thread From: Eli Zaretskii @ 2011-01-20 2:12 UTC (permalink / raw) To: Kenichi Handa; +Cc: 7626, Reiner.Steib > 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. ^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#7626: mm-charset-override-alist 2011-01-20 2:12 ` Eli Zaretskii @ 2011-01-20 3:51 ` Kenichi Handa 0 siblings, 0 replies; 44+ messages in thread From: Kenichi Handa @ 2011-01-20 3:51 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 7626, Reiner.Steib 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#7626: mm-charset-override-alist 2011-01-20 2:05 ` Kenichi Handa 2011-01-20 2:12 ` Eli Zaretskii @ 2011-02-05 13:36 ` Eli Zaretskii 2011-02-07 0:45 ` Kenichi Handa 1 sibling, 1 reply; 44+ messages in thread From: Eli Zaretskii @ 2011-02-05 13:36 UTC (permalink / raw) To: Kenichi Handa; +Cc: 7626 > 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.) ^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#7626: mm-charset-override-alist 2011-02-05 13:36 ` Eli Zaretskii @ 2011-02-07 0:45 ` Kenichi Handa [not found] ` <8339o0ts6k.fsf@gnu.org> 2011-02-07 6:07 ` Eli Zaretskii 0 siblings, 2 replies; 44+ messages in thread From: Kenichi Handa @ 2011-02-07 0:45 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 7626 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
[parent not found: <8339o0ts6k.fsf@gnu.org>]
* bug#7626: mm-charset-override-alist [not found] ` <8339o0ts6k.fsf@gnu.org> @ 2011-02-07 5:36 ` Kenichi Handa 0 siblings, 0 replies; 44+ messages in thread From: Kenichi Handa @ 2011-02-07 5:36 UTC (permalink / raw) To: 7626 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#7626: mm-charset-override-alist 2011-02-07 0:45 ` Kenichi Handa [not found] ` <8339o0ts6k.fsf@gnu.org> @ 2011-02-07 6:07 ` Eli Zaretskii 2011-10-07 0:32 ` Glenn Morris 1 sibling, 1 reply; 44+ messages in thread From: Eli Zaretskii @ 2011-02-07 6:07 UTC (permalink / raw) To: Kenichi Handa; +Cc: 7626 > 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. ^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#7626: mm-charset-override-alist 2011-02-07 6:07 ` Eli Zaretskii @ 2011-10-07 0:32 ` Glenn Morris 2011-10-07 12:14 ` Eli Zaretskii 0 siblings, 1 reply; 44+ messages in thread From: Glenn Morris @ 2011-10-07 0:32 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 7626 IIUC there were a bunch of rmail changes since this. Is this report still relevant? ^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#7626: mm-charset-override-alist 2011-10-07 0:32 ` Glenn Morris @ 2011-10-07 12:14 ` Eli Zaretskii 0 siblings, 0 replies; 44+ messages in thread From: Eli Zaretskii @ 2011-10-07 12:14 UTC (permalink / raw) To: Glenn Morris; +Cc: 7626-done > 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. ^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#7626: mm-charset-override-alist 2011-01-20 0:40 ` Eli Zaretskii 2011-01-20 1:57 ` Stefan Monnier 2011-01-20 2:05 ` Kenichi Handa @ 2011-01-20 2:27 ` Eli Zaretskii 2 siblings, 0 replies; 44+ messages in thread From: Eli Zaretskii @ 2011-01-20 2:27 UTC (permalink / raw) To: 7626 > 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. ^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#7651: 23.2.91; Rmail doesn't allow displaying text attachments conveniently 2011-01-12 6:22 ` Kenichi Handa 2011-01-12 10:57 ` bug#7626: " Eli Zaretskii @ 2011-01-12 10:58 ` Eli Zaretskii 1 sibling, 0 replies; 44+ messages in thread From: Eli Zaretskii @ 2011-01-12 10:58 UTC (permalink / raw) To: Kenichi Handa; +Cc: 7651 > 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. ^ permalink raw reply [flat|nested] 44+ messages in thread
* bug#7651: 23.2.91; Rmail doesn't allow displaying text attachments conveniently 2010-12-16 6:15 bug#7651: 23.2.91; Rmail doesn't allow displaying text attachments conveniently Eli Zaretskii 2010-12-16 7:08 ` Kenichi Handa @ 2011-10-19 7:56 ` Eli Zaretskii 1 sibling, 0 replies; 44+ messages in thread From: Eli Zaretskii @ 2011-10-19 7:56 UTC (permalink / raw) To: 7651-done This bug was fixed quite some time ago, it's time to close it. ^ permalink raw reply [flat|nested] 44+ messages in thread
end of thread, other threads:[~2011-10-19 7:56 UTC | newest] Thread overview: 44+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-12-16 6:15 bug#7651: 23.2.91; Rmail doesn't allow displaying text attachments conveniently Eli Zaretskii 2010-12-16 7:08 ` Kenichi Handa 2010-12-16 17:33 ` Eli Zaretskii 2010-12-17 15:28 ` Eli Zaretskii 2010-12-24 4:50 ` Kenichi Handa 2010-12-24 8:17 ` Andreas Schwab 2010-12-24 11:22 ` Kenichi Handa 2010-12-27 11:08 ` Kenichi Handa 2010-12-30 12:39 ` Chong Yidong 2011-01-04 5:36 ` Kenichi Handa 2011-01-04 6:35 ` Eli Zaretskii 2011-01-01 11:00 ` Eli Zaretskii 2011-01-01 15:26 ` Eli Zaretskii 2011-01-04 7:16 ` Kenichi Handa 2011-01-04 5:01 ` Kenichi Handa 2011-01-04 6:34 ` Eli Zaretskii 2011-01-07 7:13 ` Kenichi Handa 2011-01-07 7:53 ` Eli Zaretskii 2011-01-12 6:22 ` Kenichi Handa 2011-01-12 10:57 ` bug#7626: " Eli Zaretskii 2011-01-13 1:21 ` Kenichi Handa 2011-01-13 12:12 ` Eli Zaretskii 2011-01-14 4:23 ` Kenichi Handa 2011-01-18 8:07 ` bug#7626: mm-charset-override-alist (was: bug#7626: bug#7651: 23.2.91; Rmail doesn't allow displaying text attachments conveniently) Reiner Steib 2011-01-18 15:10 ` Eli Zaretskii 2011-01-18 18:00 ` bug#7626: mm-charset-override-alist Stefan Monnier 2011-01-19 21:23 ` Reiner Steib 2011-01-20 0:40 ` Eli Zaretskii 2011-01-20 1:57 ` Stefan Monnier 2011-01-20 2:08 ` Eli Zaretskii 2011-01-20 15:32 ` Stefan Monnier 2011-01-20 15:37 ` Eli Zaretskii 2011-01-20 2:05 ` Kenichi Handa 2011-01-20 2:12 ` Eli Zaretskii 2011-01-20 3:51 ` Kenichi Handa 2011-02-05 13:36 ` Eli Zaretskii 2011-02-07 0:45 ` Kenichi Handa [not found] ` <8339o0ts6k.fsf@gnu.org> 2011-02-07 5:36 ` Kenichi Handa 2011-02-07 6:07 ` Eli Zaretskii 2011-10-07 0:32 ` Glenn Morris 2011-10-07 12:14 ` Eli Zaretskii 2011-01-20 2:27 ` Eli Zaretskii 2011-01-12 10:58 ` bug#7651: 23.2.91; Rmail doesn't allow displaying text attachments conveniently Eli Zaretskii 2011-10-19 7:56 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).