On Fri, 27 May 2011 03:27:35 -0700, Jameson Graef Rollins <jroll...@finestructure.net> wrote: > Ok. So I very much hope this patch series satisfies those who were > bothered by the part renumbering that was happening when PGP/MIME > parts were processed. For signed messages we no longer modify the > parts at all, so numbering always remains constant, and for encrypted > messages the numbering will only change if the encrypted message is > itself multipart.
That sounds much better to me. I think the remaining issues I have with
the patch series are very minor and can be applied after the fact. I'd
push the series right now except that I happen to have no network access
at the moment. [I'm queueing up this message for delivery, so if I'm on
top of things when I'm back in range, I'll push right away.]
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).
I promise you don't need to rebuild this branch anymore, nor keep asking
me to merge it. Go enjoy a good US-holiday weekend. You've earned it!
That said, here are the (minor) issues I have with the series:
* More tests should be switched to the new text_expect_equal_file
This isn't a problem with the series---but will be a nice
fix. I think the current "notmuch search --output=tags *" 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.
* The series duplicates some existing code into a new
emacs_deliver_message
The previously-existing code should be removed and replaced with
a call to the new function.
* Should we set the crypto option to verify/decrypt by default?
That would certainly be convenient for me at least.
For people who don't want this, they can set the variable to
nil. But then they'll still have the following issue:
* I'm not a fan of the M-RET option for decrypting a message
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.
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 can't actually get decryption to work for me. :-(
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.
My first guess is that this is due to the fact that gpg-agent
can't be run on my system (Debian unstable):
$ gpg-agent
gpg-agent: symbol lookup error: /usr/lib/libassuan.so.0: undefined
symbol: gpg_err_set_errno
I've got a Debian bug report queued up for this.
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?
Anyway, I know that not everyone has this same problem with the
series, so I'm not blocking it for this.
-Carl
--
carl.d.wo...@intel.com
pgpV0zSaGyo3c.pgp
Description: PGP signature
_______________________________________________ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
