3 bugs in Rmail

3 bugs in Rmail

[Eli Zaretskii]

Would someone please take a look at these 3 bug reports?

  http://lists.gnu.org/archive/html/help-gnu-emacs/2011-01/msg00315.html
  http://lists.gnu.org/archive/html/help-gnu-emacs/2011-01/msg00316.html
  http://lists.gnu.org/archive/html/help-gnu-emacs/2011-01/msg00317.html

You will see in the followups that reverting to sendmail-user-agent
resolved all of them, so the problems are probably because we switched
to message-user-agent in Emacs 23.2.  I asked DJ Delorie to submit bug
reports, but I don't see he did.  However, I'm sure he will supply
details if needed.

Re: 3 bugs in Rmail

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

> http://lists.gnu.org/archive/html/help-gnu-emacs/2011-01/msg00315.html

In mail-mode, C-c C-c deletes the window and returns to the Rmail buffer
because of this specialized code in mail-bury:

        (with-current-buffer
            (window-buffer (next-window (selected-window) 'not))
          (setq rmail-flag (eq major-mode 'rmail-mode))
          ...)
   (if rmail-flag
       ;; If the Rmail buffer has a summary, show that.
       (if summary-buffer (switch-to-buffer summary-buffer)
         (delete-window))
     (switch-to-buffer newbuf))))))

So, one solution is to add this to message-bury, or make message-bury an
alias for mail-bury.  But this code doesn't seem terribly clean.

A better alternative may be to specify a `mail-bury-function' variable,
let Rmail set that variable, and change both mail-mode and message-mode
to respect `mail-bury-function'.  Anyone have any better ideas?

Re: 3 bugs in Rmail

[Stefan Monnier]

>> http://lists.gnu.org/archive/html/help-gnu-emacs/2011-01/msg00315.html
> In mail-mode, C-c C-c deletes the window and returns to the Rmail buffer
> because of this specialized code in mail-bury:

>         (with-current-buffer
>             (window-buffer (next-window (selected-window) 'not))
>           (setq rmail-flag (eq major-mode 'rmail-mode))
>           ...)
>    (if rmail-flag
>        ;; If the Rmail buffer has a summary, show that.
>        (if summary-buffer (switch-to-buffer summary-buffer)
>          (delete-window))
>      (switch-to-buffer newbuf))))))

> So, one solution is to add this to message-bury, or make message-bury an
> alias for mail-bury.  But this code doesn't seem terribly clean.

Yes, it's pretty hackish and ugly.

> A better alternative may be to specify a `mail-bury-function' variable,
> let Rmail set that variable, and change both mail-mode and message-mode
> to respect `mail-bury-function'.  Anyone have any better ideas?

Maybe rather than mail-bury-function, it could be
a mail-callback-function, i.e. not meant explicitly for burying but more
generally for returning to the caller.  I guess the difference would be
only in the name, tho.


        Stefan

Re: 3 bugs in Rmail

[Chong Yidong]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Maybe rather than mail-bury-function, it could be
> a mail-callback-function, i.e. not meant explicitly for burying but more
> generally for returning to the caller.  I guess the difference would be
> only in the name, tho.

In either case, this probably involves the non-backward compatible
change of adding a new arg to compose-mail and the subsequent
composition functions.

So, my plan is to add the hack from mail-bury to message-bury on the
emacs-23 branch, then work on the cleaner solution on the trunk.

Re: 3 bugs in Rmail

[Stefan Monnier]

>> Maybe rather than mail-bury-function, it could be
>> a mail-callback-function, i.e. not meant explicitly for burying but more
>> generally for returning to the caller.  I guess the difference would be
>> only in the name, tho.
> In either case, this probably involves the non-backward compatible
> change of adding a new arg to compose-mail and the subsequent
> composition functions.

It can be passed via dynamic-scoping.


        Stefan

Re: 3 bugs in Rmail

[Chong Yidong]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> In either case, this probably involves the non-backward compatible
>> change of adding a new arg to compose-mail and the subsequent
>> composition functions.
>
> It can be passed via dynamic-scoping.

That would be inconsistent, since the other compose-mail options are all
passed in via function args.

Re: 3 bugs in Rmail

[Glenn Morris]

Eli Zaretskii wrote:

>   http://lists.gnu.org/archive/html/help-gnu-emacs/2011-01/msg00317.html

* I want "To" listed before "CC"

Not really a bug, is it?

(add-hook 'message-header-setup-hook 'message-sort-headers)

* I want to filter duplicates out of the address list (and potentially
  a custom elisp filter for what a "duplicate" is, i.e. alternate
  spellings of host names).

C-h v message-reply-to-function

 (As mentioned in the "reply" section of the Message manual.)

Re: 3 bugs in Rmail

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Glenn Morris <rgm@gnu.org>
> Date: Mon, 10 Jan 2011 17:47:10 -0500
> 
> Eli Zaretskii wrote:
> 
> >   http://lists.gnu.org/archive/html/help-gnu-emacs/2011-01/msg00317.html
> 
> * I want "To" listed before "CC"
> 
> Not really a bug, is it?
> 
> (add-hook 'message-header-setup-hook 'message-sort-headers)
> 
> * I want to filter duplicates out of the address list (and potentially
>   a custom elisp filter for what a "duplicate" is, i.e. alternate
>   spellings of host names).
> 
> C-h v message-reply-to-function
> 
>  (As mentioned in the "reply" section of the Message manual.)

The "bug" is that the behavior is different by default.  So I would
suggest to do whatever is needed to make message.el behave by default
like sendmail.el did, without any need to customize things.  After
all, the sendmail behavior is not faulty in any way, just a little bit
different, right?

Re: 3 bugs in Rmail

[Glenn Morris]

>> * I want "To" listed before "CC"

Turns out this is a message.el bug.

rmail-start-mail calls compose-mail with
OTHER-HEADERS = '(("in-reply-to" . <in-reply-to>) ("cc" . <cc-string>)
    ("references" . <ref-string>))

The doc of compose-mail says:

      OTHER-HEADERS is an alist specifying additional header fields.
      Elements look like (HEADER . VALUE) where both HEADER and VALUE
      are strings.
      ^^^^^^^^^^^
so rmail is doing the right thing.

With message-user-agent, compose-mail calls message-mail.
This however expects OTHER-HEADERS to have elements of the form
(SYMBOL . VALUE). This is in contradiction to the doc of compose-mail.


The funnt header order comes from the fact that message-mail passes
the headers through to message-setup and message-setup-1. The latter
basically inserts headers in the order specified by
message-header-format-alist. Any elements not present in that list are
inserted first. Since the elements of message-header-format-alist are
symbols and the test is done with assq, the strings "cc" and
"in-reply-to" are not found in that list and so end up being inserted
first in the reply buffer.

Re: 3 bugs in Rmail

[Glenn Morris]

BTW, message.el's use of symbols and assq for header-name tests all
over the place is also bad because even if you intern string headers,
they have to have the same case in order to match, when mail headers
are case-insensitive. sendmail-user-agent-compose on other hand uses
assoc-string with case-folding and member-ignore-case, so it does not
have such issues.

Re: 3 bugs in Rmail

[Glenn Morris]

Glenn Morris wrote:

> With message-user-agent, compose-mail calls message-mail.
> This however expects OTHER-HEADERS to have elements of the form
> (SYMBOL . VALUE). This is in contradiction to the doc of compose-mail.

Hah, this is a 13-year old bug:

http://groups.google.com/group/gnu.emacs.bug/browse_thread/thread/bb4a20e4fb294e2b/

(predates lists.gnu.org archives)

Re: 3 bugs in Rmail

[Glenn Morris]

Installed some kind of fix in emacs-23.