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

Attachment: pgpV0zSaGyo3c.pgp
Description: PGP signature

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

Reply via email to