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

diff --git a/README.md b/README.md
index ae59f06..35d110e 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-show.el b/autocrypt-notmuch-show.el
new file mode 100644
index 0000000..ee1e385
--- /dev/null
+++ b/autocrypt-notmuch-show.el
@@ -0,0 +1,53 @@
+;;; autocrypt-notmuch-show.el --- Autocrypt for notmuch -*- lexical-binding:t -*-
+
+;; Author: Idiomdrottning <sandra.snan@idiomdrottning.org>
+;; Based on autocrypt MUA extensions by Philip Kaludercic
+
+;; This file is NOT part of Emacs.
+;;
+;; This file is in the public domain, to the extent possible under law,
+;; published under the CC0 1.0 Universal license.
+;;
+;; For a full copy of the CC0 license see
+;; https://creativecommons.org/publicdomain/zero/1.0/legalcode
+
+;;; Commentary:
+
+;; MUA specific functions for notmuch-show
+
+;; Setup example:
+;; (setup (:package autocrypt)
+;;   (:hook-into notmuch-show-mode message-mode))
+
+;; Or, old school:
+;; (require 'autocrypt)
+;; (require 'autocrypt-message)
+;; (add-hook 'message-mode-hook #'autocrypt-mode)
+;; (require 'autocrypt-notmuch-show)
+;; (add-hook 'notmuch-show-hook #'autocrypt-mode)
+
+;;; Code:
+
+(require 'autocrypt)
+
+(declare-function notmuch-show-view-raw-message "notmuch-show" ())
+
+;;;###autocrypt
+(defun autocrypt-notmuch-show--install ()
+  "Install autocrypt hooks for notmuch."
+  (add-hook 'notmuch-show-hook #'autocrypt-process-header nil t))
+
+(defun autocrypt-notmuch-show--uninstall ()
+  "Remove autocrypt hooks for notmuch."
+  (remove-hook 'notmuch-show-hook #'autocrypt-process-header t))
+
+(defun autocrypt-notmuch-show--get-header (header)
+  "Ask notmuch to return HEADER."
+  (save-window-excursion
+    (notmuch-show-view-raw-message)
+    (prog1 (mail-fetch-field header)
+      (kill-buffer (current-buffer)))))
+
+(provide 'autocrypt-notmuch-show)
+
+;;; autocrypt-notmuch.el ends here
diff --git a/autocrypt.el b/autocrypt.el
index 0fe2ba0..bf0a699 100644
--- a/autocrypt.el
+++ b/autocrypt.el
@@ -109,6 +109,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-show))
         (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.30.2

Thank you for your patch, I assume everything works as intended? I don't
use notmuch, so I cannot test it right now.

I'll insert my questions inline:

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

> ---
>  README.md                 |  1 +
>  autocrypt-notmuch-show.el | 53 +++++++++++++++++++++++++++++++++++++++

Why "notmuch-show" and not just "notmuch"?

>  autocrypt.el              |  1 +
>  3 files changed, 55 insertions(+)
>  create mode 100644 autocrypt-notmuch-show.el
>
> diff --git a/README.md b/README.md
> index ae59f06..35d110e 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-show.el b/autocrypt-notmuch-show.el
> new file mode 100644
> index 0000000..ee1e385
> --- /dev/null
> +++ b/autocrypt-notmuch-show.el
> @@ -0,0 +1,53 @@
> +;;; autocrypt-notmuch-show.el --- Autocrypt for notmuch -*- lexical-binding:t -*-
> +
> +;; Author: Idiomdrottning <sandra.snan@idiomdrottning.org>
> +;; Based on autocrypt MUA extensions by Philip Kaludercic
> +
> +;; This file is NOT part of Emacs.
> +;;
> +;; This file is in the public domain, to the extent possible under law,
> +;; published under the CC0 1.0 Universal license.
> +;;
> +;; For a full copy of the CC0 license see
> +;; https://creativecommons.org/publicdomain/zero/1.0/legalcode
> +
> +;;; Commentary:
> +
> +;; MUA specific functions for notmuch-show
> +
> +;; Setup example:
> +;; (setup (:package autocrypt)
> +;;   (:hook-into notmuch-show-mode message-mode))

Is it necessary to add a setup example here? The other backends just
mentioned the right hook to add autocrypt-mode to.

> +;; Or, old school:
> +;; (require 'autocrypt)
> +;; (require 'autocrypt-message)
> +;; (add-hook 'message-mode-hook #'autocrypt-mode)
> +;; (require 'autocrypt-notmuch-show)
> +;; (add-hook 'notmuch-show-hook #'autocrypt-mode)

It shouldn't be necessary to require all these features.  All the right
functions should be autoloaded, so all you should need is a add-hook
(that is also what the setup expression from above expands to).

> +;;; Code:
> +
> +(require 'autocrypt)
> +
> +(declare-function notmuch-show-view-raw-message "notmuch-show" ())
> +
> +;;;###autocrypt
> +(defun autocrypt-notmuch-show--install ()
> +  "Install autocrypt hooks for notmuch."
> +  (add-hook 'notmuch-show-hook #'autocrypt-process-header nil t))
> +
> +(defun autocrypt-notmuch-show--uninstall ()
> +  "Remove autocrypt hooks for notmuch."
> +  (remove-hook 'notmuch-show-hook #'autocrypt-process-header t))
> +
> +(defun autocrypt-notmuch-show--get-header (header)
> +  "Ask notmuch to return HEADER."
> +  (save-window-excursion
> +    (notmuch-show-view-raw-message)

Does this flicker? I assume that `notmuch-show-view-raw-message`
displays and selects a new buffer with all the headers, right? Maybe
there is a lower-level function that you could use to avoid the
save-window-excursion?  If not, this should be fine.

> +    (prog1 (mail-fetch-field header)

A require on mail-utils would be nice in this case. Or does notmuch
provide an alternative function to query headers?

> +      (kill-buffer (current-buffer)))))

> +(provide 'autocrypt-notmuch-show)
> +
> +;;; autocrypt-notmuch.el ends here
> diff --git a/autocrypt.el b/autocrypt.el
> index 0fe2ba0..bf0a699 100644
> --- a/autocrypt.el
> +++ b/autocrypt.el
> @@ -109,6 +109,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-show))

Could there be any issues with the order of the backend we should consider?

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

-- 
	Philip Kaludercic

Philip Kaludercic <philipk@posteo.net> writes:

> Thank you for your patch, I assume everything works as intended? I don't
> use notmuch, so I cannot test it right now.

The notmuch part of it (inserting peers into autocrypt-peers) works.
There's an issue with message mode that I'm still looking into:

It both encrypts AND adds a
header, and the autocrypt-recommendation for the set of recipients and
senders I'm testing with says 'discourage

> Why "notmuch-show" and not just "notmuch"?

This is due to a quirk in autocrypt's extension system, where it needs
to find a matching -mode. There is no notmuch-mode, it uses five other
more specific submodes instead. notmuch-show-mode is where you can read
the emails and grab the relevant headers.

> Is it necessary to add a setup example here? The other backends just
> mentioned the right hook to add autocrypt-mode to.

Sure, I can change that.

Three reasons:

1. I had a hard time understanding from your instructions how to set it
   up (before I read the source code).
2. I wanted people to remember to also hook it into message-mode.
3. I wanted people to get that it's notmuch-show-hook and neither
   notmuch-mode-hook nor notmuch-show-mode-hook.

But, for that latter reason, the setup code is probably incorrect. I
removed it (in a patch I'll send shortly) in favor of the "old school"
method (which is what I've tested).

> It shouldn't be necessary to require all these features.  All the right
> functions should be autoloaded, so all you should need is a add-hook

Just tested that and you're right. Good catch.

> Does this flicker? I assume that `notmuch-show-view-raw-message`
> displays and selects a new buffer with all the headers, right? Maybe
> there is a lower-level function that you could use to avoid the
> save-window-excursion?  If not, this should be fine.

Good idea. I didn't notice any flicker, but theoretically yes. Fixed in
v2. I just went ahead and fixed the corresponding issue in
autocrypt-mu4.el too. (It was using an unnecessary with-current-buffer
wrapper since it was saving window excursion & switching windows anyway.
The new patch is more low-level.

> A require on mail-utils would be nice in this case.

It's autoloaded.

> Could there be any issues with the order of the backend we should consider?

What do you mean here?

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

diff --git a/README.md b/README.md
index ae59f06..35d110e 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-show.el b/autocrypt-notmuch-show.el
new file mode 100644
index 0000000..392c922
--- /dev/null
+++ b/autocrypt-notmuch-show.el
@@ -0,0 +1,48 @@
+;;; autocrypt-notmuch-show.el --- Autocrypt for notmuch -*- lexical-binding:nil -*-
+
+;; Author: Idiomdrottning <sandra.snan@idiomdrottning.org>
+;; Based on autocrypt MUA extensions by Philip Kaludercic
+
+;; This file is NOT part of Emacs.
+;;
+;; This file is in the public domain, to the extent possible under law,
+;; published under the CC0 1.0 Universal license.
+;;
+;; For a full copy of the CC0 license see
+;; https://creativecommons.org/publicdomain/zero/1.0/legalcode
+
+;;; Commentary:
+
+;; MUA specific functions for notmuch-show
+
+;; Setup example:
+;; (add-hook 'message-mode-hook #'autocrypt-mode)
+;; (add-hook 'notmuch-show-hook #'autocrypt-mode)
+
+;;; Code:
+
+(require 'autocrypt)
+
+(declare-function notmuch-show-view-raw-message "notmuch-show" ())
+
+;;;###autocrypt
+(defun autocrypt-notmuch-show--install ()
+  "Install autocrypt hooks for notmuch."
+  (add-hook 'notmuch-show-hook #'autocrypt-process-header nil t))
+
+(defun autocrypt-notmuch-show--uninstall ()
+  "Remove autocrypt hooks for notmuch."
+  (remove-hook 'notmuch-show-hook #'autocrypt-process-header t))
+
+(defun autocrypt-notmuch-show--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"
+                    (notmuch-show-get-message-id)))
+    (mail-fetch-field header)))
+
+(provide 'autocrypt-notmuch-show)
+
+;;; autocrypt-notmuch.el ends here
diff --git a/autocrypt.el b/autocrypt.el
index 0fe2ba0..bf0a699 100644
--- a/autocrypt.el
+++ b/autocrypt.el
@@ -109,6 +109,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-show))
         (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.30.2

---
 autocrypt-mu4e.el | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/autocrypt-mu4e.el b/autocrypt-mu4e.el
index cfa4e42..4f3546b 100644
--- a/autocrypt-mu4e.el
+++ b/autocrypt-mu4e.el
@@ -35,10 +35,12 @@
 
 (defun autocrypt-mu4e--get-header (header)
   "Ask mu4e to return HEADER."
-  (save-window-excursion
-    (with-current-buffer (mu4e-view-raw-message)
-      (prog1 (mail-fetch-field header)
-        (kill-buffer (current-buffer))))))
+  (let ((path (mu4e-message-field-at-point :path)))
+    (unless (and path (file-readable-p path))
+      (mu4e-error "Not a readable file: %S" path))
+    (with-temp-buffer
+      (insert-file-contents path)
+      (mail-fetch-field header))))
 
 (provide 'autocrypt-mu4e)
 
-- 
2.30.2

By "adds a header" I meant a Do-Discouraged-Autocrypt: no" header.

> By "adds a header" I meant a Do-Discouraged-Autocrypt: no" header.

It got stripped away by autocrypt and then I went chasing for bugs in the 
lists.sr.ht source code… 💔

It doesn't correctly set my friend's preference in the autocrypt-peers val 
to mutual even though looking at his headers, that's what he wants.

(That explains the recommendation.)

Just to clarify, I don't think the issues are related to this particular 
Notmuch commit/patch. It does seem to receive the header correctly, as far 
as I can tell.

(It seems my first message was not sent out, so I'll try it again.)

Two points I forgot to mention in my last message:

1. I intend to publish autocrypt.el on GNU ELPA, if I am ever to finish
   the implementation (see the README for what is missing).  Have you
   signed the copyright agreement for Emacs?

2. Are you familiar with the previous attempt to add autocrypt.el
   support to Notmuch?

   https://www.mail-archive.com/notmuch@notmuchmail.org/msg50795.html

   If ELPA should turn out to be an issue, I would consider if
   implementing the necessary functions directly in notmuch would be a
   possible alternative.  More on that below.

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

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Thank you for your patch, I assume everything works as intended? I don't
>> use notmuch, so I cannot test it right now.
>
> The notmuch part of it (inserting peers into autocrypt-peers) works.
> There's an issue with message mode that I'm still looking into:
>
> It both encrypts AND adds a
> header, and the autocrypt-recommendation for the set of recipients and
> senders I'm testing with says 'discourage
>
>> Why "notmuch-show" and not just "notmuch"?
>
> This is due to a quirk in autocrypt's extension system, where it needs
> to find a matching -mode. There is no notmuch-mode, it uses five other
> more specific submodes instead. notmuch-show-mode is where you can read
> the emails and grab the relevant headers.

Ok, in that case we could also try and update the extension system to
make this work better.

As an idea: The current implementation checks if
autocrypt-backend-function is bound, if autocrypt support were
implemented in notmuch directly, this could be set to a buffer local
variable that returns the right function for the right command.

>> Is it necessary to add a setup example here? The other backends just
>> mentioned the right hook to add autocrypt-mode to.
>
> Sure, I can change that.
>
> Three reasons:
>
> 1. I had a hard time understanding from your instructions how to set it
>    up (before I read the source code).

Oh, sorry about that.  Do you still recall what your issue was?  If
there is a way to clarify what has to be done, I am open to suggestions.

> 2. I wanted people to remember to also hook it into message-mode.

Good point.  Currently this is only implied in the rmail + message
example used in the README.

> 3. I wanted people to get that it's notmuch-show-hook and neither
>    notmuch-mode-hook nor notmuch-show-mode-hook.

My objection was not towards indicating what hook to use, just that
setup seems inappropriate (and I say that as the author of the package).

> But, for that latter reason, the setup code is probably incorrect. I
> removed it (in a patch I'll send shortly) in favor of the "old school"
> method (which is what I've tested).
>
>> It shouldn't be necessary to require all these features.  All the right
>> functions should be autoloaded, so all you should need is a add-hook
>
> Just tested that and you're right. Good catch.

1+

>> Does this flicker? I assume that `notmuch-show-view-raw-message`
>> displays and selects a new buffer with all the headers, right? Maybe
>> there is a lower-level function that you could use to avoid the
>> save-window-excursion?  If not, this should be fine.
>
> Good idea. I didn't notice any flicker, but theoretically yes. Fixed in
> v2. I just went ahead and fixed the corresponding issue in
> autocrypt-mu4.el too. (It was using an unnecessary with-current-buffer
> wrapper since it was saving window excursion & switching windows anyway.
> The new patch is more low-level.

1+

>> A require on mail-utils would be nice in this case.
>
> It's autoloaded.

True, but my taste is to only rely on autoloading for interactive
use-cases.  A package or library should make it's dependencies explicit
if a function is always used.

>> Could there be any issues with the order of the backend we should consider?
>
> What do you mean here?

A while back mu4e had an issue where when using the Gnus frontend, that
derives a Gnus major mode, autocrypt.el could be confused if the gnus
setup code were to be listed before mu4e, because it falsely identified
the mu4e viewer to be a Gnus buffer.  The consequence is that the wrong
hooks are modified, and autocrypt.el doesn't work as intended.

-- 
	Philip Kaludercic

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

> ---
>  README.md                 |  1 +
>  autocrypt-notmuch-show.el | 48 +++++++++++++++++++++++++++++++++++++++
>  autocrypt.el              |  1 +
>  3 files changed, 50 insertions(+)
>  create mode 100644 autocrypt-notmuch-show.el
>
> diff --git a/README.md b/README.md
> index ae59f06..35d110e 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-show.el b/autocrypt-notmuch-show.el
> new file mode 100644
> index 0000000..392c922
> --- /dev/null
> +++ b/autocrypt-notmuch-show.el
> @@ -0,0 +1,48 @@
> +;;; autocrypt-notmuch-show.el --- Autocrypt for notmuch -*- lexical-binding:nil -*-
> +
> +;; Author: Idiomdrottning <sandra.snan@idiomdrottning.org>
> +;; Based on autocrypt MUA extensions by Philip Kaludercic
> +
> +;; This file is NOT part of Emacs.
> +;;
> +;; This file is in the public domain, to the extent possible under law,
> +;; published under the CC0 1.0 Universal license.
> +;;
> +;; For a full copy of the CC0 license see
> +;; https://creativecommons.org/publicdomain/zero/1.0/legalcode
> +
> +;;; Commentary:
> +
> +;; MUA specific functions for notmuch-show
> +
> +;; Setup example:
> +;; (add-hook 'message-mode-hook #'autocrypt-mode)

If message mode required for notmuch?  Or could you also use mail-mode?
(I'm guessing most people use message-mode, so this is probably
irrelevant).

> +;; (add-hook 'notmuch-show-hook #'autocrypt-mode)
> +
> +;;; Code:
> +
> +(require 'autocrypt)
> +
> +(declare-function notmuch-show-view-raw-message "notmuch-show" ())
> +
> +;;;###autocrypt
> +(defun autocrypt-notmuch-show--install ()
> +  "Install autocrypt hooks for notmuch."
> +  (add-hook 'notmuch-show-hook #'autocrypt-process-header nil t))
> +
> +(defun autocrypt-notmuch-show--uninstall ()
> +  "Remove autocrypt hooks for notmuch."
> +  (remove-hook 'notmuch-show-hook #'autocrypt-process-header t))
> +
> +(defun autocrypt-notmuch-show--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"
> +                    (notmuch-show-get-message-id)))

I like this a lot more, my only fear is if you are opening a large
message, that this would incur an unnecessary overhead, inserting more
than the headers.  From what I see "notmuch show" has a --body flag can
be set to false to just insert the headers.  Can you verify if this wold
also work?

> +    (mail-fetch-field header)))
> +(provide 'autocrypt-notmuch-show)
> +
> +;;; autocrypt-notmuch.el ends here
> diff --git a/autocrypt.el b/autocrypt.el
> index 0fe2ba0..bf0a699 100644
> --- a/autocrypt.el
> +++ b/autocrypt.el
> @@ -109,6 +109,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-show))
>          (lambda () (and (derived-mode-p 'gnus-mode) 'gnus))
>          (lambda () (and (derived-mode-p 'rmail-mode) 'rmail))
>          (lambda () (and (derived-mode-p 'message-mode) 'message))

-- 
	Philip Kaludercic

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

> It doesn't correctly set my friend's preference in the autocrypt-peers
> val to mutual even though looking at his headers, that's what he
> wants.

I'm not quite sure I understand what you mean here.  Could you give me a
minimal example/illustration?

-- 
	Philip Kaludercic

ping?

Philip Kaludercic <philipk@posteo.net> writes:

> (It seems my first message was not sent out, so I'll try it again.)
>
> Two points I forgot to mention in my last message:
>
> 1. I intend to publish autocrypt.el on GNU ELPA, if I am ever to finish
>    the implementation (see the README for what is missing).  Have you
>    signed the copyright agreement for Emacs?
>
> 2. Are you familiar with the previous attempt to add autocrypt.el
>    support to Notmuch?
>
>    https://www.mail-archive.com/notmuch@notmuchmail.org/msg50795.html
>
>    If ELPA should turn out to be an issue, I would consider if
>    implementing the necessary functions directly in notmuch would be a
>    possible alternative.  More on that below.
>
> Sandra Snan <sandra.snan@idiomdrottning.org> writes:
>
>> Philip Kaludercic <philipk@posteo.net> writes:
>>
>>> Thank you for your patch, I assume everything works as intended? I don't
>>> use notmuch, so I cannot test it right now.
>>
>> The notmuch part of it (inserting peers into autocrypt-peers) works.
>> There's an issue with message mode that I'm still looking into:
>>
>> It both encrypts AND adds a
>> header, and the autocrypt-recommendation for the set of recipients and
>> senders I'm testing with says 'discourage
>>
>>> Why "notmuch-show" and not just "notmuch"?
>>
>> This is due to a quirk in autocrypt's extension system, where it needs
>> to find a matching -mode. There is no notmuch-mode, it uses five other
>> more specific submodes instead. notmuch-show-mode is where you can read
>> the emails and grab the relevant headers.
>
> Ok, in that case we could also try and update the extension system to
> make this work better.
>
> As an idea: The current implementation checks if
> autocrypt-backend-function is bound, if autocrypt support were
> implemented in notmuch directly, this could be set to a buffer local
> variable that returns the right function for the right command.
>
>>> Is it necessary to add a setup example here? The other backends just
>>> mentioned the right hook to add autocrypt-mode to.
>>
>> Sure, I can change that.
>>
>> Three reasons:
>>
>> 1. I had a hard time understanding from your instructions how to set it
>>    up (before I read the source code).
>
> Oh, sorry about that.  Do you still recall what your issue was?  If
> there is a way to clarify what has to be done, I am open to suggestions.
>
>> 2. I wanted people to remember to also hook it into message-mode.
>
> Good point.  Currently this is only implied in the rmail + message
> example used in the README.
>
>> 3. I wanted people to get that it's notmuch-show-hook and neither
>>    notmuch-mode-hook nor notmuch-show-mode-hook.
>
> My objection was not towards indicating what hook to use, just that
> setup seems inappropriate (and I say that as the author of the package).
>
>> But, for that latter reason, the setup code is probably incorrect. I
>> removed it (in a patch I'll send shortly) in favor of the "old school"
>> method (which is what I've tested).
>>
>>> It shouldn't be necessary to require all these features.  All the right
>>> functions should be autoloaded, so all you should need is a add-hook
>>
>> Just tested that and you're right. Good catch.
>
> 1+
>
>>> Does this flicker? I assume that `notmuch-show-view-raw-message`
>>> displays and selects a new buffer with all the headers, right? Maybe
>>> there is a lower-level function that you could use to avoid the
>>> save-window-excursion?  If not, this should be fine.
>>
>> Good idea. I didn't notice any flicker, but theoretically yes. Fixed in
>> v2. I just went ahead and fixed the corresponding issue in
>> autocrypt-mu4.el too. (It was using an unnecessary with-current-buffer
>> wrapper since it was saving window excursion & switching windows anyway.
>> The new patch is more low-level.
>
> 1+
>
>>> A require on mail-utils would be nice in this case.
>>
>> It's autoloaded.
>
> True, but my taste is to only rely on autoloading for interactive
> use-cases.  A package or library should make it's dependencies explicit
> if a function is always used.
>
>>> Could there be any issues with the order of the backend we should consider?
>>
>> What do you mean here?
>
> A while back mu4e had an issue where when using the Gnus frontend, that
> derives a Gnus major mode, autocrypt.el could be confused if the gnus
> setup code were to be listed before mu4e, because it falsely identified
> the mu4e viewer to be a Gnus buffer.  The consequence is that the wrong
> hooks are modified, and autocrypt.el doesn't work as intended.

-- 
	Philip Kaludercic

Just trying to find a free weekend to work on this ♥

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

> Just trying to find a free weekend to work on this ♥

Ok, nor a problem nor a need to hurry!

-- 
	Philip Kaludercic

---
 autocrypt-notmuch-show.el | 13 +++++++------
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/autocrypt-notmuch-show.el b/autocrypt-notmuch-show.el
index 392c922..b19f748 100644
--- a/autocrypt-notmuch-show.el
+++ b/autocrypt-notmuch-show.el
@@ -36,12 +36,13 @@
 
 (defun autocrypt-notmuch-show--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"
-                    (notmuch-show-get-message-id)))
-    (mail-fetch-field header)))
+  (let ((message-id (notmuch-show-get-message-id)))
+    (with-temp-buffer
+      (let ((coding-system-for-read 'no-conversion))
+        (call-process notmuch-command
+                      nil t nil "show" "--format=raw" "--body=false"
+                      message-id))
+      (mail-fetch-field header))))
 
 (provide 'autocrypt-notmuch-show)
 
-- 
2.30.2

It stopped working after I put in the "no-flickering" change and today I 
finally had a moment to see why, and patch it. So that was an issue on my 
end, fixed with this patch ♥

Additionally, I've found that autoload, I don't really know how that works 
but I've had to require the stuff in .emacs after all. That's also on my 
end but not sure what autoload annotations to put in, and where.

Third, the other issue, which as far as I can tell (I might be wrong) isn't 
related to this patch or notmuch specific, but what it is is that in autocrypt 
peers, my friend isn't getting recorded as "mutual" even though, when I 
look at their most recent headers, they have that setting on in k9.

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

> It stopped working after I put in the "no-flickering" change and today
> I finally had a moment to see why, and patch it. So that was an issue
> on my end, fixed with this patch ♥

Ok, great!  The fix makes sense.

> Additionally, I've found that autoload, I don't really know how that
> works but I've had to require the stuff in .emacs after all. That's
> also on my end but not sure what autoload annotations to put in, and
> where.

My apologies, but I am not sure what you are trying to say here?

FWIW: When a function is autoloaded, the function symbol is set to a
"stub" that when funcalled, loads the necessary feature, replaces itself
with the real function and then continue to call this real function.
This means that while evaluating code that contains an autoloaded
function, the actual logic might always be interrupted by a "load".
When all functions are loaded immediately, everything that has to be
loaded is loaded at once.  That is at least my reasoning.

> Third, the other issue, which as far as I can tell (I might be wrong)
> isn't related to this patch or notmuch specific, but what it is is
> that in autocrypt peers, my friend isn't getting recorded as "mutual"
> even though, when I look at their most recent headers, they have that
> setting on in k9.

My peer entry for your address has "mutual", as indicated by the header
in your last message.  If there is an issue somewhere, you should be
able to locate it in autocrypt-process-header.  Maybe try edebugging the
function, to see if all the generic functions (superficially
autocrypt-get-header) are returning what they are supposed to.

Finally, I just want to briefly bring up the two questions from a
previous message again:  1. Have you signed the FSF copyright
assignment or do you not want to, 2. Have you checked if this code could
be added to notmuch instead of autocrypt?

-- 
	Philip Kaludercic

Philip Kaludercic <philipk@posteo.net> writes:
> My apologies, but I am not sure what you are trying to say here?

I'm saying that unless I have evaluated
(require 'autocrypt)
(require 'autocrypt-message)
(require 'autocrypt-notmuch-show)
it doesn't work.

In autocrypt.el there is a line like this:
;;;###autoload

That stuff still needs to be added in. It's better you or somebody who
gets it does that.

> My peer entry for your address has "mutual", as indicated by the header
> in your last message.  If there is an issue somewhere, you should be
> able to locate it in autocrypt-process-header.  Maybe try edebugging the
> function, to see if all the generic functions (superficially
> autocrypt-get-header) are returning what they are supposed to.

I believe the problem is that my friend sent some emails without mutual
and some with.

So two issues arise:

1. We don't see the messages in the order they were sent, but in the
order they are opened in Notmuch. (A dilemma: match the email we're
replying to, or the most recent setting of the user?)

2. I worry that the code doesn't update older peers. Here is autocrypt.el

(unless (assoc addr autocrypt-peers)
  (push (cons addr peer) autocrypt-peers))

> Have you signed the FSF copyright assignment or do you not want to

I can do that (if I haven't already, I'm not sure). Send it♥

> Have you checked if this code could be added to notmuch instead of
> autocrypt?

So if people wanna move it there, I'm fine with that. Here are some
reason why I sent it here instead:

1. It's a small patch to your repo but would be a huge patch on notmuch
   since it doesn't have the peer saving etc that you have.

2. This is in line with autocrypt-mu4e and similar plugins that are in
   your repo already.

3. This is specific to the Emacs interface to notmuch (it grabs the
   headers while viewing them in Emacs) and doesn't inteface with
   notmuch's binary or database at all. (Again, in line with
   autocrypt-mu4e)

4. There was a notmuch autocrypt initiative according to the autocrypt
   web page but they have gone dark. Haven't been able to contact them
   or find them.

Even though we have those reasons, again, if this code were to move into
notmuch down the line, that'd be fine by me. Why should I mind either
way?♥

Sandra

---
 autocrypt-notmuch-show.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/autocrypt-notmuch-show.el b/autocrypt-notmuch-show.el
index b19f748..e36b44b 100644
--- a/autocrypt-notmuch-show.el
+++ b/autocrypt-notmuch-show.el
@@ -23,7 +23,7 @@
 
 (require 'autocrypt)
 
-(declare-function notmuch-show-view-raw-message "notmuch-show" ())
+(declare-function notmuch-show-get-message-id "notmuch-show" ())
 
 ;;;###autocrypt
 (defun autocrypt-notmuch-show--install ()
-- 
2.30.2

I also wonder what and when the header-processing is gonna get triggered? 
In notmuch, the buffer usually shows several messages (from different senders) 
at once. The peers I have saved currently, I have from evaluating autocrypt-process-header

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

> I also wonder what and when the header-processing is gonna get
> triggered? In notmuch, the buffer usually shows several messages (from
> different senders) at once. The peers I have saved currently, I have
> from evaluating autocrypt-process-header

See my other message.  Each backend prepares the header processing on
it's own, in it's respective ...--install function by adding
autocrypt-process-header to the right hook.

-- 
	Philip Kaludercic

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

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Why "notmuch-show" and not just "notmuch"?
>
> This is due to a quirk in autocrypt's extension system, where it needs
> to find a matching -mode. There is no notmuch-mode, it uses five other
> more specific submodes instead. notmuch-show-mode is where you can read
> the emails and grab the relevant headers.

Btw, this shouldn't be an issue, you can just have to replace the

     (lambda () (and (derived-mode-p 'notmuch-show-mode) 'notmuch-show))

entry in autocrypt-backends with

     (lambda () (and (derived-mode-p 'notmuch-show-mode) 'notmuch))

-- 
	Philip Kaludercic

> Btw, this shouldn't be an issue, you can just have to replace the
> 
>      (lambda () (and (derived-mode-p 'notmuch-show-mode) 'notmuch-show))
> 
> entry in autocrypt-backends with
> 
>      (lambda () (and (derived-mode-p 'notmuch-show-mode) 'notmuch))

That sounds easy enough, thank you!

> See my other message.  Each backend prepares the header processing on
> it's own, in it's respective ...--install function by adding
> autocrypt-process-header to the right hook.

So it's easy to add a hook to when the mode has been initialized in a buffer 
(that's what my submission here already does), but, instead we wanna figure 
out a way to run it for each message in the buffer (again, the buffers show 
many messages from different senders, some of those messages are visible 
and some are closed); it works (which I've verified by calling it manually) 
when point is at a message (even a closed one).

I'll try to figure something out. The nuclear option is to have the hook 
(in a copied temp buffer) search through all the messages in the thread 
and open them, but since it calls a process for each message (and there 
can be hundreds) that's a last resort.
Instead, I wanna hook it into something more precise and specific when displaying 
the messages. I'll have to go digging 💔

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

>> See my other message.  Each backend prepares the header processing on
>> it's own, in it's respective ...--install function by adding
>> autocrypt-process-header to the right hook.
>
> So it's easy to add a hook to when the mode has been initialized in a
> buffer (that's what my submission here already does), but, instead we
> wanna figure out a way to run it for each message in the buffer
> (again, the buffers show many messages from different senders, some of
> those messages are visible and some are closed); it works (which I've
> verified by calling it manually) when point is at a message (even a
> closed one).

Exactly.  I have installed notmuch to see how "notmuch show" works, and
what I see my proposal from the other message should work.  If I
understand correctly, you are always reading a thread, right?  You can
query a list of messages like so

--8<---------------cut here---------------start------------->8---
$ notmuch show --body=false thread:0000000000000084
message{ id:X8krQv7LwzTt9DFR@ACM depth:0 match:1 excluded:0 filename:/home/philip/Downloads//mail/cur/1639849815.000130.mbox:2,
header{
Alan Mackenzie <acm@muc.de> (2020-12-03) (inbox unread)
Subject: The Emacs master is much slower than the emacs-27 branch.
From: Alan Mackenzie <acm@muc.de>
To: emacs-devel@gnu.org
Date: Thu, 03 Dec 2020 18:15:30 +0000
header}
message}
message{ id:83a6uufxuq.fsf@gnu.org depth:1 match:1 excluded:0 filename:/home/philip/Downloads//mail/cur/1639849815.000134.mbox:2,
header{
Eli Zaretskii <eliz@gnu.org> (2020-12-03) (inbox unread)
Subject: Re: The Emacs master is much slower than the emacs-27 branch.
From: Eli Zaretskii <eliz@gnu.org>
To: Alan Mackenzie <acm@muc.de>
Cc: emacs-devel@gnu.org
Date: Thu, 03 Dec 2020 22:17:33 +0200
header}
message}
message{ id:X8n9s85Zej1ZfTqd@ACM depth:2 match:1 excluded:0 filename:/home/philip/Downloads//mail/cur/1639849815.000172.mbox:2,
--8<---------------cut here---------------end--------------->8---

and then traverse the buffer.  Could you try if adding this function to
notmuch-show-hook does what it should?

--8<---------------cut here---------------start------------->8---
(defun autocrypt-notmuch--process-all-headers ()
  "Call `autocrypt-process-header' on all messages in the current thread."
  (with-temp-buffer
    (process-file "notmuch" nil t nil "show" (concat "thread:" notmuch-show-thread-id))
    (while (search-forward-regexp "header{" nil t)
      (save-restriction
	(narrow-to-page)
	(autocrypt-process-header)))))
--8<---------------cut here---------------end--------------->8---

Of course, this also needs a new get-header function.  Try just
defalias'ing the backend function to `mail-fetch-field'.

> I'll try to figure something out. The nuclear option is to have the
> hook (in a copied temp buffer) search through all the messages in the
> thread and open them, but since it calls a process for each message
> (and there can be hundreds) that's a last resort.

While it might not be necessary to start a process for every message (if
the above works), this is also something that worries me.  While I have
some ideas how performance issues could be militated, it should be more
important to establish how slow or fast the above approach really is,
and continue improving it based on those conclusions.

> Instead, I wanna hook it into something more precise and specific when
> displaying the messages. I'll have to go digging 💔

Of course, if you find something better I'd be open to suggestions.

-- 
	Philip Kaludercic