From: Jameson Graef Rollins <jrollins@finestructure.net>
To: Carl Worth <cworth@cworth.org>, notmuch@notmuchmail.org
Subject: Re: normalizing part numbering across PGP/MIME processing
In-Reply-To: <87lixr1w87.fsf@yoom.home.cworth.org>
References: <1306371680-19441-1-git-send-email-jrollins@finestructure.net>
	<1306492059-7706-1-git-send-email-jrollins@finestructure.net>
	<87lixr1w87.fsf@yoom.home.cworth.org>
User-Agent: Notmuch/0.5-170-gfa54148 (http://notmuchmail.org) Emacs/23.3.1
	(x86_64-pc-linux-gnu)
Date: Sat, 28 May 2011 14:31:08 -0700
Message-ID: <87k4daecmb.fsf@servo.factory.finestructure.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
	micalg=pgp-sha256; protocol="application/pgp-signature"
Precedence: list

--=-=-=
Content-Transfer-Encoding: quoted-printable

On Fri, 27 May 2011 17:53:44 -0700, Carl Worth <cworth@cworth.org> wrote:
> So, well done, Jameson! You've been extremely patient as I sat on this
> patch series for *so* long, and then made you rebuild it so many
> times. I hope you think the rebuilds were at least worth it for the much
> cleaner final state, (I know that the useless waiting wasn't worth it).

w00t!  Thanks so much, Carl!  I definitely think the whole branch turned
out to be a lot cleaner in the end.

> That said, here are the (minor) issues I have with the series:
>=20
>   * More tests should be switched to the new text_expect_equal_file
>=20
> 	This isn't a problem with the series---but will be a nice
> 	fix. I think the current "notmuch search --output=3Dtags *" is
> 	broken due to a missing final newline---or at least has been
> 	broken that way recently. So it will be nice to have this
> 	support for testing a final newline.

Yes, I agree.  I'm about to send a patch series to the list that
includes a bunch of random stuff that should be include in 0.6, and it
includes some of these fixes.

>   * Should we set the crypto option to verify/decrypt by default?
>=20
> 	That would certainly be convenient for me at least.
>=20
> 	For people who don't want this, they can set the variable to
> 	nil. But then they'll still have the following issue:

I don't really have an opinion on this.  I have it set now, so whether
or not it's set by default doesn't make much difference to me.

>   * I'm not a fan of the M-RET option for decrypting a message
>=20
> 	If someone is going to have encrypted messages not decrypted by
> 	default, then they can currently decrypt by opening the message
> 	with M-RET. But I think in common use, the user is likely to
> 	only realize too late that they want to decrypt the message.
>=20
> 	So what I'd love to see is a keybinding for decrypting a message
> 	from the view of the message itself. (One natural place would be
> 	by activating the button of the encrypted part---but a
> 	keybinding to review with decryption would be fine too---likely
> 	easier to code and easier to use.)

I agree it would definitely be better to have the redisplay happen from
inside the message show.  That would be much cleaner and more intuitive.
It will require a bit of work to add something like a "redisplay" in
notmuch-show, but I see no reason it can't be done.

>   * I can't actually get decryption to work for me. :-(
>=20
> 	When I run "notmuch show --decrypt" on a message encrypted with
> 	my public key I get a segfault within libgmime, specifically in
> 	the g_mime_session_request_passwd function.

Yikes!

> 	My first guess is that this is due to the fact that gpg-agent
> 	can't be run on my system (Debian unstable):
>=20
> 	$ gpg-agent
> 	gpg-agent: symbol lookup error: /usr/lib/libassuan.so.0: undefined symbo=
l: gpg_err_set_errno
>=20
> 	I've got a Debian bug report queued up for this.

hrm, that's very strange, unfortunately I'm not sure what's happening
there.  Bug in gpg-agent, I assume?

> 	I also tried running the same "notmuch show" command without
> 	gpg-agent installed. How is libgmime supposed to actually
> 	request a password in a case like this?

That's a good question, actually, and I don't actually know the answer.

Ok, so more release-candidate/0.6 patches to follow.

Thanks again for pushing all this stuff through, Carl.

jamie.

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBCAAGBQJN4WmcAAoJEO00zqvie6q8SdkP/1tBGU4rYZX4+bM8SUxZ0YkM
FJzEDf7KV1IddqZxJRVZxbRB/K6zAJUPioG2KuLqF7dP53HyuGbcQF43eyc/zXzF
Q6esAaMasL6dGvpa8jzKJSEQhqG8ZdTv5Am8/BOK1buzGb+xljB71g8s+lczzXa2
n8mifD07jKEcraZwlGQPSxPshuEQf6gklad8TASzkamUsxAW68n8YJfZ5zM2EZvR
qHOvkc27sxf6E2nFxyNYp8YciyVv60SN3pQAuwlCM0SiehCjKjdH7Olu+jZkxK0b
pCrTXxRq0tUR6XkOX802Dm1Qpepk9Mwy/WXxerMlvWxeNfdjVamibCzZbAkNXG5b
+E5UeSA8JpTA4viFiZeekNUeD986aXgbRm/YWQZy8QWWvCzfz+8Rh0xC1SrMCVFs
TLR9IiT0+ehzuo5nBgQszcR/PGdDAtSS/P5596W2OiKjvHkwkYp/i9qzFnOuK6zJ
77o4hqGJIyPynlXyRtv8f3symW9IEBj9ZyiSwj1Jb1ceK+r1D+Prkh3nFEhnlC9d
nIFdoOEE6rJG4Ssbl2WBTj7F18SPwi14JV8c5W72ZQy8YiqqaYqGP9GBEv/okReD
rKarRJftJqB/eA9GenKNeURnhhs/INCAVEavJ52jdkKQHrlUkA7qZLxVnlhv7r1D
6+V1auGVz7ACliIIcE7s
=x4jM
-----END PGP SIGNATURE-----
--=-=-=--