From: Thomas Jost <schnouki@schnouki.net>
To: Aaron Ecay <aaronecay@gmail.com>, David Bremner <david@tethera.net>,
	Jameson Graef Rollins <jrollins@finestructure.net>, notmuch@notmuchmail.org
Subject: Re: [PATCH v3 1/4] emacs: Let the user choose where to compose new
	mails
In-Reply-To: <m2ty4oszji.fsf@gmail.com>
References: <87d3cx2t38.fsf@rocinante.cs.unb.ca>
	<1323797532-597-1-git-send-email-schnouki@schnouki.net>
	<1323797532-597-2-git-send-email-schnouki@schnouki.net>
	<877h1y13dv.fsf@zancas.localnet>
	<87sjklzrcn.fsf@servo.finestructure.net>
	<87r505iecz.fsf@zancas.localnet> <m2ty4oszji.fsf@gmail.com>
User-Agent: Notmuch/0.10.2+178~g8a0a6dd (http://notmuchmail.org)
	Emacs/24.0.92.1 (x86_64-unknown-linux-gnu)
Date: Fri, 06 Jan 2012 17:45:45 +0100
Message-ID: <87zke0aifa.fsf@thor.loria.fr>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
	micalg=pgp-sha1; protocol="application/pgp-signature"
Precedence: list

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Sun, 25 Dec 2011 23:54:41 -0500, Aaron Ecay <aaronecay@gmail.com> wrote:
> On Thu, 15 Dec 2011 19:50:36 -0400, David Bremner <david@tethera.net> wro=
te:
> > I think the problem is related to emacsclient.
> >=20
> > With 'm' I have the following behaviour:
> >=20
> > 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.
>=20
> 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?
>=20
> Here=E2=80=99s the recipe I used for replicating:
>=20
> 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 f=
or session)
> M-x notmuch
> m (new window is created in current frame, below the window showing notmu=
ch-hello)
> (type mail)
> C-c C-c (enter smtp settings, since emacs doesn=E2=80=99t 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:
=2D Emacs 23.3 vs Emacs 24.0.92 (23.3 from Arch [extra] repo, 24.0.92
  compiled from AUR emacs-pretest package)
=2D with and without --daemon
=2D 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:

=2D 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)

=2D 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,

=2D-=20
Thomas/Schnouki

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBAgAGBQJPByU5AAoJEMPdciX+bh5IxcYH/j1pH+uQ5kryroh+OridstY7
PZ7l/VA7W8p2OM9vtLZTRaFw+BpoSlqwC+siTYsqU9vbitgiqSKIt/t09ZoOtyDX
9CQRtDit/EDSUQSfrZVKjrdmSo5yEMbX9qyQDPk5Yj8xvh9oD/wqwARLqLodym09
DYqKj5YOEMorQktuySS6sacP6dgpNRw1yJzRQIPgbz2TSCCFPl4Z7tEgZVUt2vUx
cgbEoG8FkqNcXoYD77xLUEiwd+41xaevHTuttG5xsI0VMGuAtp7kLgKXb7givp+e
PP/q2/p0sKzamFXwjt9YRtX4YlCP+HjftcJ0SjBObXaxydlzi39eH61aFyglWlw=
=n0Cj
-----END PGP SIGNATURE-----
--=-=-=--