---
I think I have the autoload stuff set up wrong because this gets
"missing install implementation for notmuch" unless I have this:

    (require 'autocrypt-notmuch)

in my init.el.

Here is the setup I use:

    (straight-use-package '(autocrypt :host sr.ht :repo "~pkal/autocrypt"))

    (require 'autocrypt-notmuch)
    (add-hook 'message-mode-hook #'autocrypt-mode)
    (add-hook 'notmuch-show-hook #'autocrypt-mode)
    (add-hook 'notmuch-search-hook #'autocrypt-mode)
    (add-hook 'notmuch-tree-hook #'autocrypt-mode)

Works great.

It hooks into replying to messages rather than showing messages, and
the reason for that is that notmuch often shows many messages at a
time, from different people, some who are on autocrypt and some who
aren't.

Things get added to autocrypt-data.el just fine.

However, when I run gpg --list-keys the newly added keys don't show up
there, and if I have <#secure method=pgpmime mode=signencrypt> it
refuses because of the keys not being in the gpg keyring.

If I remove <#secure method=pgpmime mode=signencrypt> from the message
before sending it, it does encrypt but that's an inconvenience since I
have the gpg keyring method for people who aren't on autocrypt; I have
to know which people are in autocrypt-data.el and could safely have
the <#secure method=pgpmime mode=signencrypt> removed.

That is a message-mode issue, and I didn't touch the message-mode part
of things, but just FWIW.

 README.md            |  1 +
 autocrypt-notmuch.el | 94 ++++++++++++++++++++++++++++++++++++++++++++
 autocrypt.el         |  1 +
 3 files changed, 96 insertions(+)
 create mode 100644 autocrypt-notmuch.el

diff --git a/README.md b/README.md
index b1af7e6..b2fa3eb 100644
--- a/README.md
+++ b/README.md
@@ -10,6 +10,7 @@ Currently, it supports:
 - Rmail, as a viewer
 - Gnus, as a viewer
 - mu4e, as a viewer
+- notmuch, as a viewer
 - message, as a composer
 
 As of writing, this package doesn't fully implement the autocrypt
diff --git a/autocrypt-notmuch.el b/autocrypt-notmuch.el
new file mode 100644
index 0000000..1a2784a
--- /dev/null
+++ b/autocrypt-notmuch.el
@@ -0,0 +1,94 @@
+;; Copyright (C) 2020-2023  Free Software Foundation, Inc.
+
+;;; autocrypt-notmuch.el --- Autocrypt for notmuch -*- lexical-binding:nil -*-
+
+;; Author: Idiomdrottning <sandra.snan@idiomdrottning.org>
+;; Based on autocrypt MUA extensions by Philip Kaludercic
+
+;; This program is free software; you can redistribute it and/or modify
+;; it under the terms of the GNU General Public License as published by
+;; the Free Software Foundation, either version 3 of the License, or
+;; (at your option) any later version.
+
+;; This program is distributed in the hope that it will be useful,
+;; but WITHOUT ANY WARRANTY; without even the implied warranty of
+;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;; GNU General Public License for more details.
+
+;; You should have received a copy of the GNU General Public License
+;; along with this program.  If not, see <https://www.gnu.org/licenses/>.
+
+;;; Commentary:
+
+;; MUA specific functions for notmuch
+
+;; Setup example:
+;; (add-hook 'message-mode-hook #'autocrypt-mode)
+;; (add-hook 'notmuch-show-hook #'autocrypt-mode)
+;; (add-hook 'notmuch-search-hook #'autocrypt-mode)
+;; (add-hook 'notmuch-tree-hook #'autocrypt-mode)
+
+;;; Code:
+
+(require 'autocrypt)
+
+(declare-function notmuch-call-notmuch-sexp "notmuch")
+(declare-function notmuch-command-notmuch-sexp "notmuch")
+(declare-function notmuch-search-find-thread-id "notmuch")
+(declare-function notmuch-show-get-message-id "notmuch")
+(declare-function notmuch-tree-get-message-id "notmuch")
+
+(defvar autocrypt-message-id)
+(defvar notmuch-command (if (boundp 'notmuch-command) notmuch-command "notmuch"))
+
+(defun autocrypt-notmuch-search-rep-adv (&rest r)
+  (let* ((thread-id (notmuch-search-find-thread-id))
+         (autocrypt-message-id
+          (with-temp-buffer
+            (plist-get
+             (plist-get (notmuch-call-notmuch-sexp "reply" "--format=sexp" thread-id) :original)
+             :id))))
+    (when autocrypt-message-id
+      (autocrypt-process-header))))
+
+(defun autocrypt-notmuch-tree-rep-adv (&rest r)
+  (let ((autocrypt-message-id (notmuch-tree-get-message-id)))
+    (autocrypt-process-header)))
+
+(defun autocrypt-notmuch-show-rep-adv (&rest r)
+  (let ((autocrypt-message-id (notmuch-show-get-message-id)))
+    (autocrypt-process-header)))
+
+(defun autocrypt-notmuch-process-sexp-original (original)
+  (let ((autocrypt-message-id (plist-get original :id)))
+    (autocrypt-process-header)))
+
+;;;###autocrypt
+(defun autocrypt-notmuch--install ()
+  "Install autocrypt hooks for notmuch."
+  (if (boundp 'notmuch-mua-reply-functions)
+      (add-hook 'notmuch-mua-reply-functions #'autocrypt-notmuch-process-sexp-original)
+    (progn
+      (advice-add 'notmuch-search-reply-to-thread-sender :before #'autocrypt-notmuch-search-rep-adv)
+      (advice-add 'notmuch-tree-reply-sender :before #'autocrypt-notmuch-tree-rep-adv)
+      (advice-add 'notmuch-show-reply :before #'autocrypt-notmuch-show-rep-adv))))
+
+(defun autocrypt-notmuch--uninstall ()
+  "Remove autocrypt hooks for notmuch."
+  (remove-hook 'notmuch-mua-reply-functions #'autocrypt-notmuch-process-sexp-original)
+  (advice-remove 'notmuch-search-reply-to-thread-sender #'autocrypt-notmuch-search-rep-adv)
+  (advice-remove 'notmuch-tree-reply-sender #'autocrypt-notmuch-tree-rep-adv)
+  (advice-remove 'notmuch-show-reply #'autocrypt-notmuch-show-rep-adv))
+
+(defun autocrypt-notmuch--get-header (header)
+  "Ask notmuch to return `header'."
+  (with-temp-buffer
+    (let ((coding-system-for-read 'no-conversion))
+      (call-process notmuch-command
+                    nil t nil "show" "--format=raw" "--body=false"
+                    autocrypt-message-id))
+    (mail-fetch-field header)))
+
+(provide 'autocrypt-notmuch)
+
+;;; autocrypt-notmuch.el ends here
diff --git a/autocrypt.el b/autocrypt.el
index d03c86b..1c1b136 100644
--- a/autocrypt.el
+++ b/autocrypt.el
@@ -117,6 +117,7 @@ Every member of this list has to be an instance of the
 
 (defvar autocrypt-backends
   (list (lambda () (and (derived-mode-p 'mu4e-main-mode 'mu4e-view-mode) 'mu4e))
+        (lambda () (and (derived-mode-p 'notmuch-show-mode 'notmuch-search-mode 'notmuch-tree-mode) 'notmuch))
         (lambda () (and (derived-mode-p 'gnus-mode) 'gnus))
         (lambda () (and (derived-mode-p 'rmail-mode) 'rmail))
         (lambda () (and (derived-mode-p 'message-mode) 'message))
-- 
2.39.2

Another weird thing about message-mode is that format-flowed /
use-hard-newlines doesn't work quite right on messages that get
encrypted, but that's again not really an autocrypt specific issue
afaict.

If you have any questions about the patch just LMK

Sandra Snan <sandra.snan@idiomdrottning.org> writes:

> ---
> I think I have the autoload stuff set up wrong because this gets
> "missing install implementation for notmuch" unless I have this:
>
>     (require 'autocrypt-notmuch)
>
> in my init.el.

> Here is the setup I use:
>
>     (straight-use-package '(autocrypt :host sr.ht :repo "~pkal/autocrypt"))
>
>     (require 'autocrypt-notmuch)

This is certainly not intended, but I don't know if this is an issue
related to the straight package manager.

>     (add-hook 'message-mode-hook #'autocrypt-mode)
>     (add-hook 'notmuch-show-hook #'autocrypt-mode)
>     (add-hook 'notmuch-search-hook #'autocrypt-mode)
>     (add-hook 'notmuch-tree-hook #'autocrypt-mode)
>
> Works great.
>
> It hooks into replying to messages rather than showing messages, and
> the reason for that is that notmuch often shows many messages at a
> time, from different people, some who are on autocrypt and some who
> aren't.

I am afraid I don't get the issue, why does it matter if not everyone
uses autocrypt or not, when you would expect to gather more data by
hooking into showing messages?

> Things get added to autocrypt-data.el just fine.
>
> However, when I run gpg --list-keys the newly added keys don't show up
> there, and if I have <#secure method=pgpmime mode=signencrypt> it
> refuses because of the keys not being in the gpg keyring.
>
> If I remove <#secure method=pgpmime mode=signencrypt> from the message
> before sending it, it does encrypt but that's an inconvenience since I
> have the gpg keyring method for people who aren't on autocrypt; I have
> to know which people are in autocrypt-data.el and could safely have
> the <#secure method=pgpmime mode=signencrypt> removed.

Hmm, this might be an issue in autocrypt.el or autocrypt-message.el
itself, I will have to investigate.

> That is a message-mode issue, and I didn't touch the message-mode part
> of things, but just FWIW.
>
>  README.md            |  1 +
>  autocrypt-notmuch.el | 94 ++++++++++++++++++++++++++++++++++++++++++++
>  autocrypt.el         |  1 +
>  3 files changed, 96 insertions(+)
>  create mode 100644 autocrypt-notmuch.el

Another thing, I am not sure if you want me to apply this message as
the commit message.  I'd usually expect the commit message to describe
motivate and contextualise the changes.

> diff --git a/README.md b/README.md
> index b1af7e6..b2fa3eb 100644
> --- a/README.md
> +++ b/README.md
> @@ -10,6 +10,7 @@ Currently, it supports:
>  - Rmail, as a viewer
>  - Gnus, as a viewer
>  - mu4e, as a viewer
> +- notmuch, as a viewer
>  - message, as a composer
>  
>  As of writing, this package doesn't fully implement the autocrypt
> diff --git a/autocrypt-notmuch.el b/autocrypt-notmuch.el
> new file mode 100644
> index 0000000..1a2784a
> --- /dev/null
> +++ b/autocrypt-notmuch.el
> @@ -0,0 +1,94 @@
> +;; Copyright (C) 2020-2023  Free Software Foundation, Inc.
> +
> +;;; autocrypt-notmuch.el --- Autocrypt for notmuch -*- lexical-binding:nil -*-
> +
> +;; Author: Idiomdrottning <sandra.snan@idiomdrottning.org>
> +;; Based on autocrypt MUA extensions by Philip Kaludercic

This is not a proper header, it would be better to move it to the
commentary section.

> +
> +;; This program is free software; you can redistribute it and/or modify
> +;; it under the terms of the GNU General Public License as published by
> +;; the Free Software Foundation, either version 3 of the License, or
> +;; (at your option) any later version.
> +
> +;; This program is distributed in the hope that it will be useful,
> +;; but WITHOUT ANY WARRANTY; without even the implied warranty of
> +;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> +;; GNU General Public License for more details.
> +
> +;; You should have received a copy of the GNU General Public License
> +;; along with this program.  If not, see <https://www.gnu.org/licenses/>.
> +
> +;;; Commentary:
> +
> +;; MUA specific functions for notmuch
> +
> +;; Setup example:

Add a blank line here, or perhaps even describe this is prose.

> +;; (add-hook 'message-mode-hook #'autocrypt-mode)
> +;; (add-hook 'notmuch-show-hook #'autocrypt-mode)
> +;; (add-hook 'notmuch-search-hook #'autocrypt-mode)
> +;; (add-hook 'notmuch-tree-hook #'autocrypt-mode)
> +
> +;;; Code:
> +
> +(require 'autocrypt)
>
> +(declare-function notmuch-call-notmuch-sexp "notmuch")
> +(declare-function notmuch-command-notmuch-sexp "notmuch")
> +(declare-function notmuch-search-find-thread-id "notmuch")
> +(declare-function notmuch-show-get-message-id "notmuch")
> +(declare-function notmuch-tree-get-message-id "notmuch")

Perhaps we should look into requiring notmuch here?  Also, if you use
`declare-function', you should also specify the assumed argument list,
so that the byte compiler can warn you more effectively when calling a
function the wrong way.

> +(defvar autocrypt-message-id)

A documentation string would be nice.  Also, this variable is specific
to this file, so I'd say it would make sense to call it
`autocrypt-notmuch-message-id'.

> +(defvar notmuch-command (if (boundp 'notmuch-command) notmuch-command "notmuch"))

Declaring a variable by itself seems iffy to me, perhaps it would also be
better to declare the variable as `autocrypt-notmuch-command'.  The code
can be slightly simplified by writing

  (or (bound-and-true-p notmuch-command) "notmuch")

> +
> +(defun autocrypt-notmuch-search-rep-adv (&rest r)
> +  (let* ((thread-id (notmuch-search-find-thread-id))
> +         (autocrypt-message-id
> +          (with-temp-buffer

Why the temporary buffer here?  It would be good to document this with a comment.

> +            (plist-get
> +             (plist-get (notmuch-call-notmuch-sexp "reply" "--format=sexp" thread-id) :original)
> +             :id))))
> +    (when autocrypt-message-id
> +      (autocrypt-process-header))))
> +
> +(defun autocrypt-notmuch-tree-rep-adv (&rest r)
> +  (let ((autocrypt-message-id (notmuch-tree-get-message-id)))
> +    (autocrypt-process-header)))
> +
> +(defun autocrypt-notmuch-show-rep-adv (&rest r)
> +  (let ((autocrypt-message-id (notmuch-show-get-message-id)))
> +    (autocrypt-process-header)))
> +
> +(defun autocrypt-notmuch-process-sexp-original (original)
> +  (let ((autocrypt-message-id (plist-get original :id)))
> +    (autocrypt-process-header)))
> +
> +;;;###autocrypt
> +(defun autocrypt-notmuch--install ()
> +  "Install autocrypt hooks for notmuch."
> +  (if (boundp 'notmuch-mua-reply-functions)
> +      (add-hook 'notmuch-mua-reply-functions #'autocrypt-notmuch-process-sexp-original)
> +    (progn
> +      (advice-add 'notmuch-search-reply-to-thread-sender :before #'autocrypt-notmuch-search-rep-adv)
> +      (advice-add 'notmuch-tree-reply-sender :before #'autocrypt-notmuch-tree-rep-adv)
> +      (advice-add 'notmuch-show-reply :before #'autocrypt-notmuch-show-rep-adv))))

Is there any particular reason you chose to add the advice as :before?

> +(defun autocrypt-notmuch--uninstall ()
> +  "Remove autocrypt hooks for notmuch."
> +  (remove-hook 'notmuch-mua-reply-functions #'autocrypt-notmuch-process-sexp-original)
> +  (advice-remove 'notmuch-search-reply-to-thread-sender #'autocrypt-notmuch-search-rep-adv)
> +  (advice-remove 'notmuch-tree-reply-sender #'autocrypt-notmuch-tree-rep-adv)
> +  (advice-remove 'notmuch-show-reply #'autocrypt-notmuch-show-rep-adv))
> +
> +(defun autocrypt-notmuch--get-header (header)
> +  "Ask notmuch to return `header'."
> +  (with-temp-buffer
> +    (let ((coding-system-for-read 'no-conversion))
> +      (call-process notmuch-command
> +                    nil t nil "show" "--format=raw" "--body=false"
> +                    autocrypt-message-id))
> +    (mail-fetch-field header)))
> +
> +(provide 'autocrypt-notmuch)
> +
> +;;; autocrypt-notmuch.el ends here
> diff --git a/autocrypt.el b/autocrypt.el
> index d03c86b..1c1b136 100644
> --- a/autocrypt.el
> +++ b/autocrypt.el
> @@ -117,6 +117,7 @@ Every member of this list has to be an instance of the
>  
>  (defvar autocrypt-backends
>    (list (lambda () (and (derived-mode-p 'mu4e-main-mode 'mu4e-view-mode) 'mu4e))
> +        (lambda () (and (derived-mode-p 'notmuch-show-mode 'notmuch-search-mode 'notmuch-tree-mode) 'notmuch))

Emacs 30 has changed the signature if `derived-mode-p' and wants the
modes to be passed as a single argument.  We should follow this
convention.

>          (lambda () (and (derived-mode-p 'gnus-mode) 'gnus))
>          (lambda () (and (derived-mode-p 'rmail-mode) 'rmail))
>          (lambda () (and (derived-mode-p 'message-mode) 'message))
> 2

Sandra Snan <sandra.snan@idiomdrottning.org> writes:

> Another weird thing about message-mode is that format-flowed /
> use-hard-newlines doesn't work quite right on messages that get
> encrypted, but that's again not really an autocrypt specific issue
> afaict.

I don't know anything about that either.

Sandra Snan <sandra.snan@idiomdrottning.org> writes:

> If you have any questions about the patch just LMK

Sorry, I was just somewhat busy the last few days and didn't manage to
respond to your patch in time.

Philip Kaludercic <philipk@posteo.net> writes:
> This is certainly not intended, but I don't know if this is an 
> issue related to the straight package manager. 

Ah, got it! That makes sense. Straight has its own way of 
declaring hooks like this that'll use instead.

> I am afraid I don't get the issue, why does it matter if not 
> everyone uses autocrypt or not, when you would expect to gather 
> more data by hooking into showing messages? 

Oh, so rewriting it to scrape every single message in a thread, 
you mean? But some of those threads I'm in are thousands of posts 
long.

For the gnus and mu4e modes, you don't try to fetch autocrypt for 
every message in your inbox, right? Same here.

There would be another issue also:

In, say, Gnus, when you run Gnus, it runs autocrypt-gnus--install, 
and that puts a local hook in gnus-select-article-hook so that 
when you select an article it runs the autocrypt-process-header. 
And then running the autocrypt-process-header it can get the 
message-id even though it's a thunk, it can do that from the 
current buffer.   That's the assumed way autocrypt.el wants to 
work.   Both those two assumptions break with notmuch.   With 
notmuch, someone can write notmuch-show and get prompted for a 
thread-id and then it opens that thread-id directly. There is not 
a separate mode for "here are all the mails where I can run the 
install hook" followed by "here is one individual mail".   If I 
were to do it the same way autocrypt-gnus or autocrypt-mu4e does 
it, what happens is that the notmuch-show-mode-hook installer runs 
when the notmuch-show-mode itself runs, runs, adds the hook, but 
does not run autocrypt-process-header.

Hooking into replying solved it. You grab the key from the person 
you wanna reply to and then encrypt to them.

>> However, when I run gpg --list-keys the newly added keys don't 
>> show up there, and if I have <#secure method=pgpmime 
>> mode=signencrypt> it refuses because of the keys not being in 
>> the gpg keyring. 
>> 
>> If I remove <#secure method=pgpmime mode=signencrypt> from the 
>> message before sending it, it does encrypt but that's an 
>> inconvenience since I have the gpg keyring method for people 
>> who aren't on autocrypt; I have to know which people are in 
>> autocrypt-data.el and could safely have the <#secure 
>> method=pgpmime mode=signencrypt> removed. 
> 
> Hmm, this might be an issue in autocrypt.el or 
> autocrypt-message.el itself, I will have to investigate. 

It still works, it's just that I have to remember who I only have 
in autocrypt and who I only have in the keyring (and some are in 
both).  This is related to message and not to this notmuch patch.

> Another thing, I am not sure if you want me to apply this 
> message as the commit message.  I'd usually expect the commit 
> message to describe motivate and contextualise the changes. 

I was following advice from this post: 
https://kparal.wordpress.com/2011/08/03/git-tip-of-the-day-introduction-text-when-emailing-patches/

The commit message itself was the part above the --- (i.e. blank, 
since the title Add MUA support for notmuch was enough).


>> +;; Author: Idiomdrottning <sandra.snan@idiomdrottning.org> +;; 
>> Based on autocrypt MUA extensions by Philip Kaludercic 
> 
> This is not a proper header, it would be better to move it to 
> the commentary section. 

Yes, I wanted to talk to you about that; I noticed that line after 
sending the patch and I didn't wanna send a new one just to remove 
it, but now that you've pointed it out I will. The reason I wrote 
two years ago was based on your mu4e stuff, but this new version 
is all different.

Also I was trying some sorta CC-0 thing to not have to FSF assign, 
but, now that I have signed the FSF papers it's GPL all the way.♥

>> +(declare-function notmuch-call-notmuch-sexp "notmuch") 
>> +(declare-function notmuch-command-notmuch-sexp "notmuch") 
>> +(declare-function notmuch-search-find-thread-id "notmuch") 
>> +(declare-function notmuch-show-get-message-id "notmuch") 
>> +(declare-function notmuch-tree-get-message-id "notmuch") 
> 
> Perhaps we should look into requiring notmuch here?

That's a much better solution, yes. Thank you.

>> +(defvar notmuch-command (if (boundp 'notmuch-command) 
>> notmuch-command "notmuch")) 
> 
> Declaring a variable by itself seems iffy to me

Don't worry, that line of code goes away with (require 'notmuch).♥

> Why the temporary buffer here?  It would be good to document 
> this with a comment. 

Temp buffers reduce display flickering when shelling out to the 
notmuch binary. I'll add comments.

> Is there any particular reason you chose to add the advice as 
> :before? 

Yes, it's much simpler if getting the autocrypt key is before 
composing the reply message.

Also note that if the hook is available (in upcoming versions of 
notmuch, I added that hook to notmuch for the purposes of this 
autocrypt plugin you're reviewing now), the advice isn't needed. 
It's a workaround for when the hook isn't there.

>>  (defvar autocrypt-backends 
>>    (list (lambda () (and (derived-mode-p 'mu4e-main-mode 
>>    'mu4e-view-mode) 'mu4e)) 
>> +        (lambda () (and (derived-mode-p 'notmuch-show-mode 
>> 'notmuch-search-mode 'notmuch-tree-mode) 'notmuch)) 
> 
> Emacs 30 has changed the signature if `derived-mode-p' and wants 
> the modes to be passed as a single argument.  We should follow 
> this convention.

Of all your comments so far, which have been great and have been 
stuff I could either explain here and/or fix in the next version 
patch, here is the first thing I really need your help on because 
I'm on Emacs 28.

So you mean it takes a list of modes like this?

    (derived-mode-p '(notmuch-show-mode notmuch-search-mode 
    notmuch-tree-mode))

That's so strange to me.

How can we make something that works in both old and new?
 
    (and (derived-mode-p 'notmuch-show-mode) 
         (derived-mode-p 'notmuch-search-mode) (derived-mode-p 
         'notmuch-tree-mode))

Would ↑ this ↑ work in both? Working off the guess / assumtion 
that it's yes, I'll send a v2 that does it that way, if that's not 
right either I'll have to send a v3.

I can change how mu4e does it in the same commit since it has the 
same format.

>> If you have any questions about the patch just LMK 
> 
> Sorry, I was just somewhat busy the last few days and didn't 
> manage to respond to your patch in time. 

Right, not really a deadline to these things (as you know, I waited a
whole year before getting back to it after the FSF sorted out the
papers). Just wanted to let you know you could ask if you thought some
things were weird.

Sandra Snan <sandra.snan@idiomdrottning.org> writes:
> if that's not right either I'll have to send a v3. 

Eww! It was definitively not right! As I'm testing this on 
notmuch, I'm getting "Missing install implementation for mu4e" 
errors.

After restoring autocrypt.el to the way I sent it in v1, the 
changes you suggested for autocrypt-notmuch.el in v2 work great.

So here for this derived-p stuff on Emacs 30 I'm a li'l bit at a loss.

I have new data fresh from ever more testing!

TL;DR about the message-mode issues: don't worry, do nothing. 
Deets follow.

Turns out this format-flowed issue:

Sandra Snan <sandra.snan@idiomdrottning.org> writes:

> Another weird thing about message-mode is that format-flowed / 
> use-hard-newlines doesn't work quite right on messages that get 
> encrypted, but that's again not really an autocrypt specific 
> issue afaict. 

was when sending to a guy who I already had in my keyring, e.g. it 
was not encrypted by autocrypt.el but by the standard gpg stuff, 
and it was the standard gpg stuff that mangled the newlines.

Today I sent to a guy who I do NOT have in my GPG keyring but who 
does use autocrypt and here's what happened:

1. At the end of all that follows, the end result was that the 
message was encrypted just fine! I checked the raws and with 
another MUA.

2. Also autocrypt did not mangle the newlines at all! Great job 
autocrypt!

2. But it was like "No encrypt key for 
<the-guys-username@hotmail.com>; skip it? (y or n)"

3. And when I hit "y", it sent, and then autocrypt (which I have 
set to mutual, which isn't the default, which it should be) 
encrypted it.

4. I have another package which automatically adds: 
 
     <#secure method=pgpmime mode=signencrypt> 
 
to everything and that's what's going on here. And actually things 
work OK the way they are:

If it says I don't have it in my key I'm just like "OK fine then" 
and hit y, and autocrypt steps in in like a catcher in the rye to 
sort things out.  And if I do have it in my key it's also fine if 
it uses the older non-autocrypt GPG stuff for that person even 
though newlines get mangled and the key might be older.

And even though it would be much nicer if these packages played better
together and that the other one could know whether or not there was an
autocrypt key for the person etc etc, that better UX is something I can
and probably will hack up in the future, but the way it works now is not
the end of the world.

Sandra Snan <sandra.snan@idiomdrottning.org> writes:

> Today I sent to a guy who I do NOT have in my GPG keyring but 
> who  does use autocrypt and here's what happened: 
> 
> 1. At the end of all that follows, the end result was that the 
> message was encrypted just fine! I checked the raws and with 
> another MUA. 

Uh-oh, trouble in paradise over here because he replied that he could
not decrypt the message. He is in autocrypt-peers but I don't know how
to decode that data to trouble shoot