Re: [PATCH v3 1/4] emacs: Let the user choose where to compose new mails
Thomas Jost schno...@schnouki.net writes: AFAICT, Emacs 23 is just buggy in this case. By reading the code of message-send-and-exit and message-bury [1], here is what happens when you call message-send-buffer-and-exit with message-kill-buffer-on-exit set to nil: - message is sent - buffer is buried with burry-buffer - message-bury: if the window is dedicated and its frame not the only visible frame, then this frame is deleted OK, I guess I can live with the behaviour as an emacs 23 bug, but I think we should warn the user of this bug somewhere prominently, perhaps in the customize message. Effectively users of emacs23 and emacsclient will probably want to avoid the new-window setting. d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v3 1/4] emacs: Let the user choose where to compose new mails
Le 15 avril 2012 à 16:52 CEST, David Bremner a écrit : Jameson Graef Rollins jroll...@finestructure.net writes: I think the issues that David was experiencing have to do with flakiness in emacs's dedicated windows, not in this patch itself. Thomas, Did you have a change to investigate this as proposed in id:87zke0aifa@thor.loria.fr? David, Sorry for the delay. I did investigate a little bit, but I did not try to write a patch to fix the wrong behaviour in Emacs 23. AFAICT, Emacs 23 is just buggy in this case. By reading the code of message-send-and-exit and message-bury [1], here is what happens when you call message-send-buffer-and-exit with message-kill-buffer-on-exit set to nil: - message is sent - buffer is buried with burry-buffer - message-bury: if the window is dedicated and its frame not the only visible frame, then this frame is deleted which explains what happens in Emacs 23 both in daemon and non-daemon mode. In Emacs 24 [2], here is what happens: - message is sent - message-bury: buffer is buried with bury-buffer which is (obviously?) correct. Really, this looks like a bug in Emacs 23 to me. Emacs 24 has been fixed by Gnus commits [3] and [4] (maybe [3] is enough, I didn't try). Users of Emacs 23 can probably just use an up-to-date version of Gnus to have this issue fixed. So I'm not sure it would make sense to try to come up with a workaround in my patch, nor if it would be worth it. Maybe just adding a message suggesting Emacs 23 users to enable message-kill-buffer-on-exit if they use the Gnus version shipped with Emacs? Other than that, Jameson's commit [5] is exactly the same as the one in my tree with a better commit message, so I'm in favor of pulling it. [1] http://bzr.savannah.gnu.org/lh/emacs/emacs-23/annotate/head:/lisp/gnus/message.el [2] http://bzr.savannah.gnu.org/lh/emacs/emacs-24/annotate/head:/lisp/gnus/message.el [3] http://git.gnus.org/cgit/gnus.git/commit/?id=30eb6d24d30bc028fce91a0c62044c5dc1fdd90e [4] http://git.gnus.org/cgit/gnus.git/commit/?id=e3fc7cb33eb07dd3b48cfc72f0cada1f1edbcb85 [5] id:1334436137-6099-1-git-send-email-jroll...@finestructure.net Regards, -- Thomas/Schnouki pgpU4xJp7PmDM.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v3 1/4] emacs: Let the user choose where to compose new mails
Jameson Graef Rollins jroll...@finestructure.net writes: I think the issues that David was experiencing have to do with flakiness in emacs's dedicated windows, not in this patch itself. Thomas, Did you have a change to investigate this as proposed in id:87zke0aifa@thor.loria.fr? d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v3 1/4] emacs: Let the user choose where to compose new mails
On Tue, Dec 13 2011, Thomas Jost schno...@schnouki.net wrote: Reusing the current window to compose a new mail may be troublesome for the user. This patch introduces a new customizable variable, notmuch-mua-compose-in, which lets the user choose where to create the mail buffer: in the current window (current and default behaviour), in a new window, or in a new frame. Hi. I have been using this patch for many months now with no problems. I really depend on it's functionality now, so I would really like to see it pushed so that I don't have to keep maintaining it on my own personal branch. I think the issues that David was experiencing have to do with flakiness in emacs's dedicated windows, not in this patch itself. jamie. pgpZbLjwUzx7D.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v3 1/4] emacs: Let the user choose where to compose new mails
On Sun, 25 Dec 2011 23:54:41 -0500, Aaron Ecay aarone...@gmail.com wrote: I just tried, and I cannot reproduce this behavior. IIUC, here is what happened to you: you set nm-mua-compose-in to 'new-window. You began a new message, this opened a new window as expected. Your emacs frame now has two windows in it. You sent this message, which deleted the window showing it. Your emacs frame was deleted as well, which made the other window, showing notmuch-hello (or some other notmuch buffer, from which you began writing the email message) disappear as well, unexpectedly. Is this a correct description of what happened? Yes, although it happened quickly enough I'm not sure the window was deleted before the frame. Here’s the recipe I used for replicating: emacs -q --daemon emacsclient -c C-x b *scratch* (add-to-list 'load-path /path/to/notmuch/emacs/) C-j (load-library notmuch) C-j C-x C-f /path/to/notmuch/emacs/notmuch-mua.el M-x eval-buffer (in order to pick up changes not in byte-compiled file) M-x customize-variable notmuch-mua-compose-in (set to 'new-window, save for session) M-x notmuch m (new window is created in current frame, below the window showing notmuch-hello) (type mail) C-c C-c (enter smtp settings, since emacs doesn’t know them) (new window disappears, the window with notmuch-hello fills whole frame) It sounds plausible. On Debian I was a bit lazy and relied on the Debian site startup file, which I attach. Note that the setting of 'new-window seems broken to me without emacsclient as well. In this case it buries the notmuch-hello buffer that the compose window was launched from. I also tried with notmuch-mua-compose-in set to 'new-frame, and got the expected behavior (m - create new frame, C-c C-c - new frame is deleted) Yes, that one seems fine; perhaps because deleting the frame is the desired outcome in this case. What version of emacs did you have this problem with? 23.3.1 50notmuch.el Description: site startup for notmuch. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v3 1/4] emacs: Let the user choose where to compose new mails
On Thu, 15 Dec 2011 19:50:36 -0400, David Bremner da...@tethera.net wrote: I think the problem is related to emacsclient. With 'm' I have the following behaviour: emacs -q --daemon M-x notmuch (to load variable definitions) M-x customize-variable notmuch-mua-compose-in (select compose in new window, save for current session) M-x notmuch m ;; new window is opened as it should be C-c C-c ;; frame is closed. I just tried, and I cannot reproduce this behavior. IIUC, here is what happened to you: you set nm-mua-compose-in to 'new-window. You began a new message, this opened a new window as expected. Your emacs frame now has two windows in it. You sent this message, which deleted the window showing it. Your emacs frame was deleted as well, which made the other window, showing notmuch-hello (or some other notmuch buffer, from which you began writing the email message) disappear as well, unexpectedly. Is this a correct description of what happened? Here’s the recipe I used for replicating: emacs -q --daemon emacsclient -c C-x b *scratch* (add-to-list 'load-path /path/to/notmuch/emacs/) C-j (load-library notmuch) C-j C-x C-f /path/to/notmuch/emacs/notmuch-mua.el M-x eval-buffer (in order to pick up changes not in byte-compiled file) M-x customize-variable notmuch-mua-compose-in (set to 'new-window, save for session) M-x notmuch m (new window is created in current frame, below the window showing notmuch-hello) (type mail) C-c C-c (enter smtp settings, since emacs doesn’t know them) (new window disappears, the window with notmuch-hello fills whole frame) I also tried with notmuch-mua-compose-in set to 'new-frame, and got the expected behavior (m - create new frame, C-c C-c - new frame is deleted) What version of emacs did you have this problem with? The window/frame handling code has undergone several intrusive rewrites post-v.23, each of which fixed some bugs and introduced others. The version I used is a trunk build from Dec. 12-ish. It would be nice to pinpoint which emacs versions/configurations show undesired behavior – this is a useful patch and it should be included once we can be sure it will work correctly. Thanks, -- Aaron Ecay ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v3 1/4] emacs: Let the user choose where to compose new mails
On Thu, 15 Dec 2011 19:50:36 -0400, David Bremner da...@tethera.net wrote: I think the problem is related to emacsclient. With 'm' I have the following behaviour: emacs -q --daemon M-x notmuch (to load variable definitions) M-x customize-variable notmuch-mua-compose-in (select compose in new window, save for current session) M-x notmuch m ;; new window is opened as it should be C-c C-c ;; frame is closed. Hey, David. What exactly is the problem here? These seems like it's actually reasonable behavior when you're using emacs in daemon mode, yes? I don't actually use notmuch with emacs daemon/client, so I'm not sure what behavior is expected. If this is an emacsclient issue, should that prevent the patch from going through? jamie. pgpYjMnw7a7Wp.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v3 1/4] emacs: Let the user choose where to compose new mails
On Fri, 16 Dec 2011 15:45:26 -0800, Jameson Graef Rollins jroll...@finestructure.net wrote: Hey, David. What exactly is the problem here? These seems like it's actually reasonable behavior when you're using emacs in daemon mode, yes? I don't actually use notmuch with emacs daemon/client, so I'm not sure what behavior is expected. The frame started by emacsclient -c is no different than a frame started with emacs. It closes when you type C-x C-c. In particular killing an emacs window should not kill the frame. With this patch, and notmuch-mua-compose-in set to new-window, notmuch does this. If this is an emacsclient issue, should that prevent the patch from going through? It is pretty disruptive to have a frame closed unexpectedly, and I think enough people use 'emacsclient -c' that this is not a use case we can dismiss. In any event, I just checked with 'emacs -q', no emacsclient, and the behaviour of 'new-window is strange there too, since it buries the notmuch window, and leaves the window containing the sent message displayed. d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v3 1/4] emacs: Let the user choose where to compose new mails
On Fri, 16 Dec 2011 21:19:37 -0400, David Bremner da...@tethera.net wrote: The frame started by emacsclient -c is no different than a frame started with emacs. It closes when you type C-x C-c. In particular killing an emacs window should not kill the frame. With this patch, and notmuch-mua-compose-in set to new-window, notmuch does this. I'm worried that this is because the behavior emacs' dedicated windows is a little flaky. I've experimented with it before and noticed some weirdnesses. It's been working for me perfectly in this context, though. I would hate to see this patch not go through, cause I'm totally addicted to this behavior at this point. What if we just added a warning to the help message for the customization variable that says the behavior with emacsclient might be a little flaky? Obviously people don't have to use this functionality, so in that sense it doesn't hurt anyone to have it there if they just don't use it, right? jamie. pgpV27hzeyjYS.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v3 1/4] emacs: Let the user choose where to compose new mails
On Thu, 15 Dec 2011 07:27:24 -0400, David Bremner da...@tethera.net wrote: There is something odd about the compose-in-new-frame support. If I run M-x notmuch-mua-mail from within an initial frame, it doesn't create a new frame but splits the current one. If I then run M-x notmuch, _that_ creates the new frame. Hey, David. I think that notmuch-mua-mail is not the correct function. It works fine if you just use 'm' to invoke a new mail compose, which actually calls notmuch-mua-new-mail. I've been using this patch and it works quite well, particularly if you set message-kill-buffer-on-exit. jamie. pgpcqw4tzqP4B.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v3 1/4] emacs: Let the user choose where to compose new mails
On Thu, 15 Dec 2011 09:18:00 -0800, Jameson Graef Rollins jroll...@finestructure.net wrote: Hey, David. I think that notmuch-mua-mail is not the correct function. It works fine if you just use 'm' to invoke a new mail compose, which actually calls notmuch-mua-new-mail. I think the problem is related to emacsclient. With 'm' I have the following behaviour: emacs -q --daemon M-x notmuch (to load variable definitions) M-x customize-variable notmuch-mua-compose-in (select compose in new window, save for current session) M-x notmuch m ;; new window is opened as it should be C-c C-c ;; frame is closed. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
