* report-emacs-bug and *mail* buffer. @ 2007-03-07 14:36 Michaël Cadilhac [not found] ` <E1HQFbl-0001tK-20@fencepost.gnu.org> 0 siblings, 1 reply; 10+ messages in thread From: Michaël Cadilhac @ 2007-03-07 14:36 UTC (permalink / raw) To: emacs-devel [-- Attachment #1.1.1: Type: text/plain, Size: 689 bytes --] Hi! I use both Gnus and report-emacs-bug, and I have a little problem : Test case: 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*. I propose the following patch that forces, in the default config, to use a new buffer each time r-e-bug is called. This is the simplest change I could came up with ; others include searching for a bug-report buffer and ask for its deletion, but the modifications are bigger. [-- Attachment #1.1.2: emacsbug.patch --] [-- Type: text/x-patch, Size: 2879 bytes --] Index: lisp/mail/emacsbug.el =================================================================== RCS file: /sources/emacs/emacs/lisp/mail/emacsbug.el,v retrieving revision 1.72 diff -B -w -c -r1.72 emacsbug.el *** lisp/mail/emacsbug.el 21 Jan 2007 02:59:07 -0000 1.72 --- lisp/mail/emacsbug.el 7 Mar 2007 13:32:56 -0000 *************** *** 89,95 **** (with-current-buffer (get-buffer-create "*Messages*") (point-max-marker))) (compose-mail reporting-address ! topic) ;; The rest of this does not execute ;; if the user was asked to confirm and said no. (rfc822-goto-eoh) --- 89,95 ---- (with-current-buffer (get-buffer-create "*Messages*") (point-max-marker))) (compose-mail reporting-address ! topic nil 'new) ;; The rest of this does not execute ;; if the user was asked to confirm and said no. (rfc822-goto-eoh) Index: lisp/simple.el =================================================================== RCS file: /sources/emacs/emacs/lisp/simple.el,v retrieving revision 1.848 diff -B -w -c -r1.848 simple.el *** lisp/simple.el 6 Mar 2007 02:18:05 -0000 1.848 --- lisp/simple.el 7 Mar 2007 13:32:59 -0000 *************** *** 4668,4679 **** (defun sendmail-user-agent-compose (&optional to subject other-headers continue switch-function yank-action send-actions) ! (if switch-function ! (let ((special-display-buffer-names nil) ! (special-display-regexps nil) ! (same-window-buffer-names nil) ! (same-window-regexps nil)) ! (funcall switch-function "*mail*"))) (let ((cc (cdr (assoc-string "cc" other-headers t))) (in-reply-to (cdr (assoc-string "in-reply-to" other-headers t))) (body (cdr (assoc-string "body" other-headers t)))) --- 4668,4674 ---- (defun sendmail-user-agent-compose (&optional to subject other-headers continue switch-function yank-action send-actions) ! ;; `switch-function' is ignored as `mail' will choose its own buffer. (let ((cc (cdr (assoc-string "cc" other-headers t))) (in-reply-to (cdr (assoc-string "in-reply-to" other-headers t))) (body (cdr (assoc-string "body" other-headers t)))) Index: lisp/ChangeLog =================================================================== RCS file: /sources/emacs/emacs/lisp/ChangeLog,v retrieving revision 1.10783 diff -C0 -r1.10783 ChangeLog *** lisp/ChangeLog 7 Mar 2007 12:50:23 -0000 1.10783 --- lisp/ChangeLog 7 Mar 2007 13:33:29 -0000 *************** *** 0 **** --- 1,8 ---- + 2007-03-07 Michaël Cadilhac <michael@cadilhac.name> + + * simple.el (sendmail-user-agent-compose): Don't consider + `switch-function' as `mail' selects its own buffer. + + * mail/emacsbug.el (report-emacs-bug): Suggest to use a new + mail buffer to `compose-mail'. + [-- Attachment #1.1.3: Type: text/plain, Size: 335 bytes --] TIA. -- | Michaël `Micha' Cadilhac | Libertude, | | http://michael.cadilhac.name | Égalitude, | | JID/MSN: | Fraternitude. | `---- michael.cadilhac@gmail.com | -- À peu près S.R. - --' [-- Attachment #1.2: Type: application/pgp-signature, Size: 188 bytes --] [-- Attachment #2: Type: text/plain, Size: 142 bytes --] _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel ^ permalink raw reply [flat|nested] 10+ messages in thread
[parent not found: <E1HQFbl-0001tK-20@fencepost.gnu.org>]
[parent not found: <87fy8bsxtp.fsf@lrde.org>]
* Re: report-emacs-bug and *mail* buffer. [not found] ` <87fy8bsxtp.fsf@lrde.org> @ 2007-03-12 1:27 ` Richard Stallman 2007-03-12 4:24 ` Katsumi Yamaoka 2007-03-12 1:27 ` Richard Stallman 1 sibling, 1 reply; 10+ messages in thread From: Richard Stallman @ 2007-03-12 1:27 UTC (permalink / raw) To: Michaël Cadilhac; +Cc: emacs-devel, ding =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? ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: report-emacs-bug and *mail* buffer. 2007-03-12 1:27 ` Richard Stallman @ 2007-03-12 4:24 ` Katsumi Yamaoka 2007-03-12 6:40 ` Miles Bader 2007-03-12 19:18 ` Richard Stallman 0 siblings, 2 replies; 10+ messages in thread From: Katsumi Yamaoka @ 2007-03-12 4:24 UTC (permalink / raw) To: rms; +Cc: ding, Michaël Cadilhac, emacs-devel >>>>> 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: report-emacs-bug and *mail* buffer. 2007-03-12 4:24 ` Katsumi Yamaoka @ 2007-03-12 6:40 ` Miles Bader 2007-03-12 19:18 ` Richard Stallman 1 sibling, 0 replies; 10+ messages in thread From: Miles Bader @ 2007-03-12 6:40 UTC (permalink / raw) To: emacs-devel; +Cc: ding 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.... ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: report-emacs-bug and *mail* buffer. 2007-03-12 4:24 ` Katsumi Yamaoka 2007-03-12 6:40 ` Miles Bader @ 2007-03-12 19:18 ` Richard Stallman 2007-03-13 0:59 ` Katsumi Yamaoka 1 sibling, 1 reply; 10+ messages in thread From: Richard Stallman @ 2007-03-12 19:18 UTC (permalink / raw) To: Katsumi Yamaoka; +Cc: michael, emacs-devel, ding >>>>> 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: report-emacs-bug and *mail* buffer. 2007-03-12 19:18 ` Richard Stallman @ 2007-03-13 0:59 ` Katsumi Yamaoka 2007-03-14 3:25 ` Richard Stallman 2007-03-14 11:48 ` Katsumi Yamaoka 0 siblings, 2 replies; 10+ messages in thread From: Katsumi Yamaoka @ 2007-03-13 0:59 UTC (permalink / raw) To: rms; +Cc: ding, michael, emacs-devel >>>>> 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, ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: report-emacs-bug and *mail* buffer. 2007-03-13 0:59 ` Katsumi Yamaoka @ 2007-03-14 3:25 ` Richard Stallman 2007-03-14 9:12 ` Katsumi Yamaoka 2007-03-14 11:48 ` Katsumi Yamaoka 1 sibling, 1 reply; 10+ messages in thread From: Richard Stallman @ 2007-03-14 3:25 UTC (permalink / raw) To: Katsumi Yamaoka; +Cc: michael, emacs-devel, ding > 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: report-emacs-bug and *mail* buffer. 2007-03-14 3:25 ` Richard Stallman @ 2007-03-14 9:12 ` Katsumi Yamaoka 0 siblings, 0 replies; 10+ messages in thread From: Katsumi Yamaoka @ 2007-03-14 9:12 UTC (permalink / raw) To: rms; +Cc: ding, michael, emacs-devel >>>>> 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, ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: report-emacs-bug and *mail* buffer. 2007-03-13 0:59 ` Katsumi Yamaoka 2007-03-14 3:25 ` Richard Stallman @ 2007-03-14 11:48 ` Katsumi Yamaoka 1 sibling, 0 replies; 10+ messages in thread From: Katsumi Yamaoka @ 2007-03-14 11:48 UTC (permalink / raw) To: ding; +Cc: rms, michael, emacs-devel [-- 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: report-emacs-bug and *mail* buffer. [not found] ` <87fy8bsxtp.fsf@lrde.org> 2007-03-12 1:27 ` Richard Stallman @ 2007-03-12 1:27 ` Richard Stallman 1 sibling, 0 replies; 10+ messages in thread From: Richard Stallman @ 2007-03-12 1:27 UTC (permalink / raw) To: Michaël Cadilhac; +Cc: emacs-devel Please install your patch, but please document `new'. ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2007-03-14 11:48 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2007-03-07 14:36 report-emacs-bug and *mail* buffer Michaël Cadilhac [not found] ` <E1HQFbl-0001tK-20@fencepost.gnu.org> [not found] ` <87fy8bsxtp.fsf@lrde.org> 2007-03-12 1:27 ` Richard Stallman 2007-03-12 4:24 ` Katsumi Yamaoka 2007-03-12 6:40 ` Miles Bader 2007-03-12 19:18 ` Richard Stallman 2007-03-13 0:59 ` Katsumi Yamaoka 2007-03-14 3:25 ` Richard Stallman 2007-03-14 9:12 ` Katsumi Yamaoka 2007-03-14 11:48 ` Katsumi Yamaoka 2007-03-12 1:27 ` Richard Stallman
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.