[PATCH 1/2] emacs: tree: allow the user to decrypt the message pane

[PATCH 1/2] emacs: tree: allow the user to decrypt the message pane

[Mark Walters]

This makes $ in the tree pane toggle decryption in the message
pane. Without this the user can only decrypt the message pane by
switching to it, or by setting decryption on globally by setting
notmuch-crypto-process-mime to t.
---

This seems an obvious extension. It may not be very useful as most
people who get encrypted messages probably set
notmuch-crypto-process-mime to t.

As an aside might it be worth making that the default
(notmuch-crypto-process-mime equal to t)?

Best wishes

Mark



emacs/notmuch-tree.el | 1 +
 1 file changed, 1 insertion(+)

diff --git a/emacs/notmuch-tree.el b/emacs/notmuch-tree.el
index 5431384..8285354 100644
--- a/emacs/notmuch-tree.el
+++ b/emacs/notmuch-tree.el
@@ -255,6 +255,7 @@ FUNC."
     (define-key map (kbd "<backtab>")  (notmuch-tree-to-message-pane #'notmuch-show-previous-button))
     (define-key map (kbd "TAB") (notmuch-tree-to-message-pane #'notmuch-show-next-button))
     (define-key map "e" (notmuch-tree-to-message-pane #'notmuch-tree-button-activate))
+    (define-key map "$" (notmuch-tree-to-message-pane #'notmuch-show-toggle-process-crypto))
 
     ;; bindings from show (or elsewhere) but we close the message pane first.
     (define-key map "f" (notmuch-tree-close-message-pane-and #'notmuch-show-forward-message))
-- 
2.1.4

[PATCH 2/2] emacs: tree: use message pane decryption state for replies

[Mark Walters]

This makes replying to a message in tree view, use the decrypted state
from the message pane if it is open. Previously it just used the
global decryption state from notmuch-crypto-process-mime.

In particular if notmuch-crypto-process-mime is nil, and the user
views the messages (which doesn't decrypt), toggles decryption in the
message pane, and then replies, the reply will be decrypted.
---

I think it makes sense to include in the reply what the user can see,
and only falling back on global defaults when needed.

However, the extra complexity for a rather extreme corner case (see
example in the commit message) may mean it's not worth doing.

Best wishes

Mark



emacs/notmuch-tree.el | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/emacs/notmuch-tree.el b/emacs/notmuch-tree.el
index 8285354..e35d382 100644
--- a/emacs/notmuch-tree.el
+++ b/emacs/notmuch-tree.el
@@ -209,6 +209,13 @@ open (if the message pane is closed it does nothing)."
        (with-selected-window notmuch-tree-message-window
 	 (call-interactively #',func)))))
 
+(defun notmuch-tree-inherit-from-message-pane (sym)
+  "Return value of SYM in message-pane if open, or tree-pane if not"
+  (if (window-live-p notmuch-tree-message-window)
+      (with-selected-window notmuch-tree-message-window
+	(symbol-value sym))
+    (symbol-value sym)))
+
 (defun notmuch-tree-button-activate (&optional button)
   "Activate BUTTON or button at point
 
@@ -226,8 +233,10 @@ FUNC."
   `(lambda ()
       ,(concat "(Close message pane and) " (documentation func t))
      (interactive)
-     (notmuch-tree-close-message-window)
-     (call-interactively #',func)))
+     (let ((notmuch-show-process-crypto
+	    (notmuch-tree-inherit-from-message-pane 'notmuch-show-process-crypto)))
+       (notmuch-tree-close-message-window)
+       (call-interactively #',func))))
 
 (defvar notmuch-tree-mode-map
   (let ((map (make-sparse-keymap)))
-- 
2.1.4

Re: [PATCH 1/2] emacs: tree: allow the user to decrypt the message pane

[David Bremner]

Mark Walters <markwalters1009@gmail.com> writes:

> This makes $ in the tree pane toggle decryption in the message
> pane. Without this the user can only decrypt the message pane by
> switching to it, or by setting decryption on globally by setting
> notmuch-crypto-process-mime to t.
> ---
>
> This seems an obvious extension. It may not be very useful as most
> people who get encrypted messages probably set
> notmuch-crypto-process-mime to t.
>

pushed to master.


> As an aside might it be worth making that the default
> (notmuch-crypto-process-mime equal to t)?

that works fine for my use case, I guess the question is how many people
use a setup where they have access to secret key material only on one
machine. Also not sure what happens to people using notmuch remotely

d