bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

rmail-reply (Emacs 22.1 rmail.el) fails when replying to self


From: emacs-bug
Subject: rmail-reply (Emacs 22.1 rmail.el) fails when replying to self
Date: Sat, 28 Jul 2007 20:49:33 -0400

Emacs version: 22.1 (emacs22-x).

Operation system: GNU/Linux, kernel version 2.6.18 (Debian 4.1.1-19).

Machine: Intel(R) Pentium(R) M processor 2.00GHz, 1GB RAM.

Problem in brief: While visiting an RMAIL buffer, viewing an email
  message that was sent by user, user types 'r' (for rmail-reply) to
  reply.  The reply command fails with message "Wrong type argument:
  stringp, nil."  It does not fail in previous versions of Emacs
  (e.g., 21.4).  It does not fail when replying to messages authored
  by others.  More details below.

  The problem can be eliminated by replacing the function definition
  for rmail-reply in rmail.el with corresponding rmail-reply function
  definition from version 21.4.

Details: A message previously sent by the Emacs user will typically
  show a "To:" header when viewed in RMAIL, but will not show a
  "From:" header.  Replying to such a message in earlier version of
  Emacs produces a *mail* buffer that looks like this:

    To: 
    CC: [recipients of original message]

  But in Emacs 22.1, the reply fails, apparently due to some recent
  changes in the function rmail-reply in rmail.el, since patching
  according to the following diff -u, effectively reverting to code
  from Emacs 21.4, restores normal operation:

--- rmail-orig.el       2007-05-25 08:43:33.000000000 -0400
+++ rmail.el    2007-07-28 19:47:31.000000000 -0400
@@ -3571,11 +3571,13 @@
                              (progn (search-forward "\n*** EOOH ***\n")
                                     (beginning-of-line) (point)))))
        (setq from (mail-fetch-field "from")
-             reply-to (or (mail-fetch-field "mail-reply-to" nil t)
-                          (mail-fetch-field "reply-to" nil t)
+             reply-to (or (mail-fetch-field "reply-to" nil t)
                           from)
+             cc (and (not just-sender)
+                     (mail-fetch-field "cc" nil t))
              subject (mail-fetch-field "subject")
              date (mail-fetch-field "date")
+             to (or (mail-fetch-field "to" nil t) "")
              message-id (mail-fetch-field "message-id")
              references (mail-fetch-field "references" nil nil t)
              resent-reply-to (mail-fetch-field "resent-reply-to" nil t)
@@ -3585,16 +3587,7 @@
 ;;;          resent-subject (mail-fetch-field "resent-subject")
 ;;;          resent-date (mail-fetch-field "resent-date")
 ;;;          resent-message-id (mail-fetch-field "resent-message-id")
-             )
-       (unless just-sender
-         (if (mail-fetch-field "mail-followup-to" nil t)
-             ;; If this header field is present, use it instead of the To and 
CC fields.
-             (setq to (mail-fetch-field "mail-followup-to" nil t))
-           (setq cc (or (mail-fetch-field "cc" nil t) "")
-                 to (or (mail-fetch-field "to" nil t) ""))))
-
-       ))
-
+             )))
     ;; Merge the resent-to and resent-cc into the to and cc.
     (if (and resent-to (not (equal resent-to "")))
        (if (not (equal to ""))
@@ -3618,12 +3611,7 @@
      ;; since they can handle the names unstripped.
      ;; I don't know whether there are other mailers that still
      ;; need the names to be stripped.
-;;;     (mail-strip-quoted-names reply-to)
-     ;; Remove unwanted names from reply-to, since Mail-Followup-To
-     ;; header causes all the names in it to wind up in reply-to, not
-     ;; in cc.  But if what's left is an empty list, use the original.
-     (let* ((reply-to-list (rmail-dont-reply-to reply-to)))
-       (if (string= reply-to-list "") reply-to reply-to-list))
+     (mail-strip-quoted-names reply-to)
      subject
      (rmail-make-in-reply-to-field from date message-id)
      (if just-sender




reply via email to

[Prev in Thread] Current Thread [Next in Thread]