Re: report-emacs-bug and *mail* buffer.

Re: report-emacs-bug and *mail* buffer.

[Richard Stallman]

    =2D message-user-agent, which calls `message-mail', ignores its
    SWITCH-FUNCTION and CONTINUE args and always open a new buffer.

Isn't that a bug?  Shouldn't message-mail obey these arguments?

Re: report-emacs-bug and *mail* buffer.

[Katsumi Yamaoka]

>>>>> In <E1HQZKI-0006hW-La@fencepost.gnu.org> Richard Stallman wrote:

>     =2D message-user-agent, which calls `message-mail', ignores its
>     SWITCH-FUNCTION and CONTINUE args and always open a new buffer.

> Isn't that a bug?  Shouldn't message-mail obey these arguments?

We will have to implement them in Gnus if those arguments are
really required, although I think it doesn't solve the problem
that `sendmail-user-agent' overrides an existing *mail* buffer.

IMHO, implementing SWITCH-FUNCTION is regression.  Because, in
the case that `mail-user-agent' is `gnus-user-agent', we can use
the `gnus-buffer-configuration' feature to customize how to pop
to a mail buffer up variously.  The valid choices include splitting
a window, making a new frame, etc.  For CONTINUE, it is hard to me
to imagine the situation where I want to use an existing *mail*
buffer in order to compose a new mail.  Anyway, that Gnus users
set `mail-user-agent' to `gnus-user-agent' is the best, I think.

Regards,

[1] http://article.gmane.org/gmane.emacs.devel/67501

Re: report-emacs-bug and *mail* buffer.

[Miles Bader]

Katsumi Yamaoka <yamaoka@jpl.org> writes:
> For CONTINUE, it is hard to me to imagine the situation where I want
> to use an existing *mail* buffer in order to compose a new mail.

I dunno, it seems perfectly reasonable to have a "continue composing
mail" command which would jump to the latest unsent message or whatever.

-Miles

-- 
We live, as we dream -- alone....

Re: report-emacs-bug and *mail* buffer.

[Richard Stallman]

    >>>>> In <E1HQZKI-0006hW-La@fencepost.gnu.org> Richard Stallman wrote:

    >     =2D message-user-agent, which calls `message-mail', ignores its
    >     SWITCH-FUNCTION and CONTINUE args and always open a new buffer.

    > Isn't that a bug?  Shouldn't message-mail obey these arguments?

    We will have to implement them in Gnus if those arguments are
    really required,

Please make them work.  It does not have to be done right now,
though.

		     although I think it doesn't solve the problem
    that `sendmail-user-agent' overrides an existing *mail* buffer.

I am not sure what that means, or whether it is really a problem,
but it is certainly a different issue.  If you want to raise it,
please send a bug report about it.

    IMHO, implementing SWITCH-FUNCTION is regression.  Because, in
    the case that `mail-user-agent' is `gnus-user-agent', we can use
    the `gnus-buffer-configuration' feature to customize how to pop
    to a mail buffer up variously.

Those features are fine, for when the caller has no preference,
but if the caller specifies a particular method, Gnus should
not just ignore it.

      For CONTINUE, it is hard to me
    to imagine the situation where I want to use an existing *mail*
    buffer in order to compose a new mail.

CONTINUE means the user has given a command to resume editing an
existing draft outgoing message.  If the user wants to "compose new
mail", he will pass nil for CONTINUE.


      Anyway, that Gnus users
    set `mail-user-agent' to `gnus-user-agent' is the best, I think.

Since I don't use Message mode or Gnus, I do not know that
message-user-agent differs from gnus-user-agent.

Does gnus-user-agent implement CONTINUE and SWITCH-FUNCTION?  If not,
the same things I said about message-user-agent apply also to
gnus-user-agent.

Re: report-emacs-bug and *mail* buffer.

[Katsumi Yamaoka]

>>>>> In <buotzwr6k2t.fsf@dhapc248.dev.necel.com> Miles Bader wrote:

> Katsumi Yamaoka <yamaoka@jpl.org> writes:
>> For CONTINUE, it is hard to me to imagine the situation where I want
>> to use an existing *mail* buffer in order to compose a new mail.

> I dunno, it seems perfectly reasonable to have a "continue composing
> mail" command which would jump to the latest unsent message or whatever.

I didn't consider such a situation because I misunderstood that
there's no interface for that in Gnus.  But now I realized
Message may call other mail-user-agent's.

>>>>> In <E1HQq23-0005uy-Ln@fencepost.gnu.org> Richard Stallman wrote:

>     We will have to implement them in Gnus if those arguments are
>     really required,

> Please make them work.  It does not have to be done right now,
> though.

I'll do it as much as possible.

> 		     although I think it doesn't solve the problem
>     that `sendmail-user-agent' overrides an existing *mail* buffer.

> I am not sure what that means, or whether it is really a problem,
> but it is certainly a different issue.  If you want to raise it,
> please send a bug report about it.

That's what Michaël Cadilhac reported in <87fy8bsxtp.fsf@lrde.org>.
Or I misunderstood it?

Anyway, I'll make an effort to implement SWITCH-FUNCTION and
CONTINUE arguments in Gnus.

Regards,

Re: report-emacs-bug and *mail* buffer.

[Richard Stallman]

    > 		     although I think it doesn't solve the problem
    >     that `sendmail-user-agent' overrides an existing *mail* buffer.

    > I am not sure what that means, or whether it is really a problem,
    > but it is certainly a different issue.  If you want to raise it,
    > please send a bug report about it.

    That's what Michaël Cadilhac reported in <87fy8bsxtp.fsf@lrde.org>.
    Or I misunderstood it?

I think there is some sort of misunderstanding here, but I don't
know what it is.  87fy8bsxtp.fsf@lrde.org does not seem to say
anything about this.  It talks about whether `new' is implemented
in OTHER mail user agents.

Re: report-emacs-bug and *mail* buffer.

[Katsumi Yamaoka]

>>>>> In <E1HRK6u-0007LJ-Ge@fencepost.gnu.org> Richard Stallman wrote:

>> 		     although I think it doesn't solve the problem
>>     that `sendmail-user-agent' overrides an existing *mail* buffer.

>> I am not sure what that means, or whether it is really a problem,
>> but it is certainly a different issue.  If you want to raise it,
>> please send a bug report about it.

>     That's what Michaël Cadilhac reported in <87fy8bsxtp.fsf@lrde.org>.
>     Or I misunderstood it?

> I think there is some sort of misunderstanding here, but I don't
> know what it is.  87fy8bsxtp.fsf@lrde.org does not seem to say
> anything about this.  It talks about whether `new' is implemented
> in OTHER mail user agents.

We might have seen the report from a different viewpoint, but I
could reproduce exactly the problem:

>>>>> In <87mz2pt92d.fsf@lrde.org> Michaël Cadilhac wrote:

> Create a new mail with Gnus with `m'. The buffer is called `*mail*'.
> Now use M-x report-emacs-bug : your Gnus mail is converted to
> mail-mode and asked for deletion. Even if you say no to deletion, the
> buffer is converted to mail-mode, but if you really want to make a bug
> report, you can't until you've close your Gnus *mail*.

The causes are:

1. A user leaves `mail-user-agent' the default, which is
   `sendmail-user-agent', even if he is a Gnus user.

2. `report-emacs-bug' calls `sendmail-user-agent-compose' by way
   of `compose-mail' because of `sendmail-user-agent'.

3. `sendmail-user-agent-compose' calls `mail', and `mail' runs
   `mail-mode' unconditionally in the *mail* buffer having
   already existed.

Michaël Cadilhac's patch makes `report-emacs-bug' give the symbol
`new' as the fourth argument CONTINUE to `compose-mail'.  A non-nil
value of CONTINUE is normally used to reuse an existing *mail*
buffer in order to compose a mail.  However, the value `new' is
special in at least `sendmail-user-agent-compose' and `mail'.
It has not been documented AFAIK, but it makes `mail' use a new
*mail* buffer.  It indeed solves the problem, but I wrote:

>>>>> In <b4m1wjvf5ru.fsf@jpl.org> Katsumi Yamaoka wrote:

> Anyway, that Gnus users set `mail-user-agent' to `gnus-user-agent'
> is the best, I think.

Regards,

Re: report-emacs-bug and *mail* buffer.

[Katsumi Yamaoka]

[-- Attachment #1: Type: text/plain, Size: 2012 bytes --]

>>>>> In <b4m8xe2t0uo.fsf@jpl.org> Katsumi Yamaoka wrote:

> Anyway, I'll make an effort to implement SWITCH-FUNCTION and
> CONTINUE arguments in Gnus.

Done.  I have not committed it yet, though.  The patch to the
v5-10 branch is attached.  It can also be applied to the Gnus
trunk with a slight hand work.

Now `gnus-user-agent' and `message-user-agent' regard CONTINUE
and SWITCH-FUNCTION arguments.  For instance, whenever you eval
the following form, you will be brought to the message buffer
named "*mail to whom*":

(let ((mail-user-agent 'gnus-user-agent))
  (compose-mail "whom" nil nil t 'pop-to-buffer))

If `message-mail-user-agent' is set to a certain agent, Message
passes SWITCH-FUNCTION and CONTINUE arguments to that agent.
For example, this lets Gnus use `sendmail-user-agent' to compose
a mail:

(let ((mail-user-agent 'gnus-user-agent)
      (message-mail-user-agent 'sendmail-user-agent))
  (compose-mail "whom" nil nil t 'pop-to-buffer))

Furthermore, I slightly changed the meaning of the nil value of
`message-generate-new-buffers' and made the value t the same as
the value `unique'.  While the nil value made a buffer with a
name such as "*mail message*" formerly, it now uses a name as
what the value `unique' uses, like "*mail to whom*".
The difference between nil and `unique' is that nil uses an
existing message buffer if any but `unique' always uses a new
message buffer.  This fits the name of the variable, doesn't it?
Note that nil distinguishes the buffer "*mail to whom*" from the
buffer "*mail*".  In other words, the value nil never uses the
existing buffer named "*mail*" when it is made to use the buffer
named "*mail to whom*".  The new value `standard' is similar to
nil but is for those who like simpler "*mail message*" names.

If there's no comment, I will install those changes.

In addition, I've also revised message-multiple-frames.el so as
to agree those changes.  It is avalable at:
ftp://ftp.jpl.org/pub/elisp/ or http://www.jpl.org/ftp/pub/elisp/

Regards,


[-- Attachment #2: message_el.patch.gz --]
[-- Type: application/x-gzip, Size: 2734 bytes --]

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel