[PATCH v3 1/4] emacs: Let the user choose where to compose new mails

[David Bremner]

Thomas Jost  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

Re: [PATCH v3 1/4] emacs: Let the user choose where to compose new mails

[David Bremner]

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

[PATCH v3 1/4] emacs: Let the user choose where to compose new mails

[Thomas Jost]

Le 15 avril 2012 ? 16:52 CEST, David Bremner a ?crit :
> Jameson Graef Rollins  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.fsf at 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-jrollins at finestructure.net"

Regards,

--
Thomas/Schnouki
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: 

Re: [PATCH v3 1/4] emacs: Let the user choose where to compose new mails

[Thomas Jost]

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

[PATCH v3 1/4] emacs: Let the user choose where to compose new mails

[David Bremner]

Jameson Graef Rollins  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.fsf at thor.loria.fr"?

d

Re: [PATCH v3 1/4] emacs: Let the user choose where to compose new mails

[David Bremner]

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

[PATCH v3 1/4] emacs: Let the user choose where to compose new mails

[Jameson Graef Rollins]

On Tue, Dec 13 2011, Thomas Jost  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.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

Re: [PATCH v3 1/4] emacs: Let the user choose where to compose new mails

[Jameson Graef Rollins]

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

[PATCH v3 1/4] emacs: Let the user choose where to compose new mails

[Thomas Jost]

On Sun, 25 Dec 2011 23:54:41 -0500, Aaron Ecay  wrote:
> On Thu, 15 Dec 2011 19:50:36 -0400, David Bremner  
> 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've used something like this (+setting message-send-mail-function,
sendmail-program, sendmail extra arguments, message-signature and
notmuch-fcc-dirs) and done the following tests:
- Emacs 23.3 vs Emacs 24.0.92 (23.3 from Arch [extra] repo, 24.0.92
  compiled from AUR emacs-pretest package)
- with and without --daemon
- setting message-kill-buffer-on-exit to nil and t

In every case, the new mail composition window opened correctly next to
the notmuch-hello window. Here is what I got after successfully sending
a test mail in every situation:

- when message-kill-buffer-on-exit is "t":
  * E23: mail buffer killed, window closed, frame still there (OK)
  * E23 daemon: same thing (OK)
  * E24: same thing (OK)
  * E24 daemon: same thing (OK)

- when message-kill-buffer-on-exit is "nil":
  * E23: mail buffer buried, window still there, frame still there
  * E23 daemon: frame was killed after sending. When restarting
emacsclient: buffer buried but still there
  * E24: mail buffer buried, window closed, frame still there (OK)
  * E24 daemon: same thing (OK)

So basically everything works as expected when mkboe is "t", and there
are issues with Emacs 23 when mkboe is "nil".

I'm very sorry for these issues, I should have done more testing with
mkboe set to "nil", and I don't think I tested Emacs 23 at all with the
latest versions of this patch. I'll try to fix that and post a new patch
in a few days.

Best regards,

-- 
Thomas/Schnouki
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: 

[PATCH v3 1/4] emacs: Let the user choose where to compose new mails

[David Bremner]

On Sun, 25 Dec 2011 23:54:41 -0500, Aaron Ecay  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


-- next part --
A non-text attachment was scrubbed...
Name: 50notmuch.el
Type: application/emacs-lisp
Size: 1274 bytes
Desc: site startup for notmuch.
URL: 

Re: [PATCH v3 1/4] emacs: Let the user choose where to compose new mails

[David Bremner]

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

[PATCH v3 1/4] emacs: Let the user choose where to compose new mails

[Aaron Ecay]

On Thu, 15 Dec 2011 19:50:36 -0400, David Bremner  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

Re: [PATCH v3 1/4] emacs: Let the user choose where to compose new mails

[Aaron Ecay]

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

[PATCH v3 1/4] emacs: Let the user choose where to compose new mails

[Tom Prince]

On Fri, 16 Dec 2011 21:19:37 -0400, David Bremner  wrote:
> On Fri, 16 Dec 2011 15:45:26 -0800, Jameson Graef Rollins  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.

So long as it is the only window in the frame, that is the behavior I
want. So it is certainly a matter of taste. I thought I had to add code
to emacs to make that happen by default though.

  Tom

[PATCH v3 1/4] emacs: Let the user choose where to compose new mails

[David Bremner]

On Fri, 16 Dec 2011 15:45:26 -0800, Jameson Graef Rollins  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

[PATCH v3 1/4] emacs: Let the user choose where to compose new mails

[Jameson Graef Rollins]

On Fri, 16 Dec 2011 21:19:37 -0400, David Bremner  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.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

[PATCH v3 1/4] emacs: Let the user choose where to compose new mails

[Jameson Graef Rollins]

On Thu, 15 Dec 2011 19:50:36 -0400, David Bremner  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.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

Re: [PATCH v3 1/4] emacs: Let the user choose where to compose new mails

[Jameson Graef Rollins]

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

[David Bremner]

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

[Jameson Graef Rollins]

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

[PATCH v3 1/4] emacs: Let the user choose where to compose new mails

[David Bremner]

On Thu, 15 Dec 2011 09:18:00 -0800, Jameson Graef Rollins  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.

[PATCH v3 1/4] emacs: Let the user choose where to compose new mails

[David Bremner]

On Tue, 13 Dec 2011 18:32:09 +0100, Thomas Jost  
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.

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.

d

Re: [PATCH v3 1/4] emacs: Let the user choose where to compose new mails

[Jameson Graef Rollins]

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

[David Bremner]

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

[PATCH v3 1/4] emacs: Let the user choose where to compose new mails

[Thomas Jost]

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.
---
 emacs/notmuch-mua.el |   40 ++--
 1 files changed, 38 insertions(+), 2 deletions(-)

diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
index 8824b08..90834d6 100644
--- a/emacs/notmuch-mua.el
+++ b/emacs/notmuch-mua.el
@@ -31,6 +31,21 @@
   :group 'notmuch
   :type 'hook)

+(defcustom notmuch-mua-compose-in 'current-window
+  "Where to create the mail buffer used to compose a new message.
+  Possible values are `current-window' (default), `new-window'
+  and `new-frame'. If set to `current-window', the mail buffer
+  will be displayed in the current window, so the old buffer will
+  be restored when the mail buffer is killed. If set to
+  `new-window' or `new-frame', the mail buffer will be displayed
+  in a new window/frame that will be destroyed when the buffer is
+  killed. You may want to customize `message-kill-buffer-on-exit'
+  accordingly."
+  :group 'notmuch
+  :type '(choice (const :tag "Compose in the current window" current-window)
+(const :tag "Compose mail in a new window"  new-window)
+(const :tag "Compose mail in a new frame"   new-frame)))
+
 (defcustom notmuch-mua-user-agent-function 'notmuch-mua-user-agent-full
   "Function used to generate a `User-Agent:' string. If this is
 `nil' then no `User-Agent:' will be generated."
@@ -48,6 +63,23 @@ list."

 ;;

+(defun notmuch-mua-get-switch-function ()
+  "Get a switch function according to `notmuch-mua-compose-in'."
+  (cond ((eq notmuch-mua-compose-in 'current-window)
+'switch-to-buffer)
+   ((eq notmuch-mua-compose-in 'new-window)
+'switch-to-buffer-other-window)
+   ((eq notmuch-mua-compose-in 'new-frame)
+'switch-to-buffer-other-frame)
+   (t (error "Invalid value for `notmuch-mua-compose-in'"
+
+(defun notmuch-mua-maybe-set-window-dedicated ()
+  "Set the selected window as dedicated according to
+`notmuch-mua-compose-in'."
+  (when (or (eq notmuch-mua-compose-in 'new-frame)
+   (eq notmuch-mua-compose-in 'new-window))
+(set-window-dedicated-p (selected-window) t)))
+
 (defun notmuch-mua-user-agent-full ()
   "Generate a `User-Agent:' string suitable for notmuch."
   (concat (notmuch-mua-user-agent-notmuch)
@@ -99,7 +131,8 @@ list."
((same-window-regexps '("\\*mail .*")))
   (notmuch-mua-mail (mail-header 'to headers)
(mail-header 'subject headers)
-   (message-headers-to-generate headers t '(to subject
+   (message-headers-to-generate headers t '(to subject))
+   nil (notmuch-mua-get-switch-function)))
 ;; insert the message body - but put it in front of the signature
 ;; if one is present
 (goto-char (point-max))
@@ -112,6 +145,7 @@ list."
   (message-goto-body))

 (defun notmuch-mua-forward-message ()
+  (funcall (notmuch-mua-get-switch-function) (current-buffer))
   (message-forward)

   (when notmuch-mua-user-agent-function
@@ -121,6 +155,7 @@ list."
   (message-sort-headers)
   (message-hide-headers)
   (set-buffer-modified-p nil)
+  (notmuch-mua-maybe-set-window-dedicated)

   (message-goto-to))

@@ -143,6 +178,7 @@ list."
   (message-sort-headers)
   (message-hide-headers)
   (set-buffer-modified-p nil)
+  (notmuch-mua-maybe-set-window-dedicated)

   (message-goto-to))

@@ -199,7 +235,7 @@ the From: address first."
   (let ((other-headers
 (when (or prompt-for-sender notmuch-always-prompt-for-sender)
   (list (cons 'from (notmuch-mua-prompt-for-sender))
-(notmuch-mua-mail nil nil other-headers)))
+(notmuch-mua-mail nil nil other-headers nil 
(notmuch-mua-get-switch-function

 (defun notmuch-mua-new-forward-message ( prompt-for-sender)
   "Invoke the notmuch message forwarding window.
-- 
1.7.8

[PATCH v3 1/4] emacs: Let the user choose where to compose new mails

[Thomas Jost]

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.
---
 emacs/notmuch-mua.el |   40 ++--
 1 files changed, 38 insertions(+), 2 deletions(-)

diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
index 8824b08..90834d6 100644
--- a/emacs/notmuch-mua.el
+++ b/emacs/notmuch-mua.el
@@ -31,6 +31,21 @@
   :group 'notmuch
   :type 'hook)
 
+(defcustom notmuch-mua-compose-in 'current-window
+  Where to create the mail buffer used to compose a new message.
+  Possible values are `current-window' (default), `new-window'
+  and `new-frame'. If set to `current-window', the mail buffer
+  will be displayed in the current window, so the old buffer will
+  be restored when the mail buffer is killed. If set to
+  `new-window' or `new-frame', the mail buffer will be displayed
+  in a new window/frame that will be destroyed when the buffer is
+  killed. You may want to customize `message-kill-buffer-on-exit'
+  accordingly.
+  :group 'notmuch
+  :type '(choice (const :tag Compose in the current window current-window)
+(const :tag Compose mail in a new window  new-window)
+(const :tag Compose mail in a new frame   new-frame)))
+
 (defcustom notmuch-mua-user-agent-function 'notmuch-mua-user-agent-full
   Function used to generate a `User-Agent:' string. If this is
 `nil' then no `User-Agent:' will be generated.
@@ -48,6 +63,23 @@ list.
 
 ;;
 
+(defun notmuch-mua-get-switch-function ()
+  Get a switch function according to `notmuch-mua-compose-in'.
+  (cond ((eq notmuch-mua-compose-in 'current-window)
+'switch-to-buffer)
+   ((eq notmuch-mua-compose-in 'new-window)
+'switch-to-buffer-other-window)
+   ((eq notmuch-mua-compose-in 'new-frame)
+'switch-to-buffer-other-frame)
+   (t (error Invalid value for `notmuch-mua-compose-in'
+
+(defun notmuch-mua-maybe-set-window-dedicated ()
+  Set the selected window as dedicated according to
+`notmuch-mua-compose-in'.
+  (when (or (eq notmuch-mua-compose-in 'new-frame)
+   (eq notmuch-mua-compose-in 'new-window))
+(set-window-dedicated-p (selected-window) t)))
+
 (defun notmuch-mua-user-agent-full ()
   Generate a `User-Agent:' string suitable for notmuch.
   (concat (notmuch-mua-user-agent-notmuch)
@@ -99,7 +131,8 @@ list.
((same-window-regexps '(\\*mail .*)))
   (notmuch-mua-mail (mail-header 'to headers)
(mail-header 'subject headers)
-   (message-headers-to-generate headers t '(to subject
+   (message-headers-to-generate headers t '(to subject))
+   nil (notmuch-mua-get-switch-function)))
 ;; insert the message body - but put it in front of the signature
 ;; if one is present
 (goto-char (point-max))
@@ -112,6 +145,7 @@ list.
   (message-goto-body))
 
 (defun notmuch-mua-forward-message ()
+  (funcall (notmuch-mua-get-switch-function) (current-buffer))
   (message-forward)
 
   (when notmuch-mua-user-agent-function
@@ -121,6 +155,7 @@ list.
   (message-sort-headers)
   (message-hide-headers)
   (set-buffer-modified-p nil)
+  (notmuch-mua-maybe-set-window-dedicated)
 
   (message-goto-to))
 
@@ -143,6 +178,7 @@ list.
   (message-sort-headers)
   (message-hide-headers)
   (set-buffer-modified-p nil)
+  (notmuch-mua-maybe-set-window-dedicated)
 
   (message-goto-to))
 
@@ -199,7 +235,7 @@ the From: address first.
   (let ((other-headers
 (when (or prompt-for-sender notmuch-always-prompt-for-sender)
   (list (cons 'from (notmuch-mua-prompt-for-sender))
-(notmuch-mua-mail nil nil other-headers)))
+(notmuch-mua-mail nil nil other-headers nil 
(notmuch-mua-get-switch-function
 
 (defun notmuch-mua-new-forward-message (optional prompt-for-sender)
   Invoke the notmuch message forwarding window.
-- 
1.7.8

___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch