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 bur
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 bur
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
>
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
>
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
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@thor.loria.fr"?
d
___
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
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
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-
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 c
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
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
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 windo
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 windo
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,
> >
On Fri, 16 Dec 2011 21:19:37 -0400, David Bremner wrote:
> 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 ac
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 beh
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 s
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 s
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 be
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 windo
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 windo
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 emacscl
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 emacsc
On Thu, 15 Dec 2011 07:27:24 -0400, David Bremner 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 fr
On Thu, 15 Dec 2011 07:27:24 -0400, David Bremner 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 fr
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
>
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
>
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 ne
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 ne
30 matches
Mail list logo
