Sandra Snan: 5
Add MUA support for notmuch
Add MUA support for notmuch
Grab message id before switching to temp buffer
Update the declaration
Fix flickering in mu4e
9 files changed, 119 insertions(+), 11 deletions(-)
(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:
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))
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 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.
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.
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.
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))
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?
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.
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))
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).
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.
+ (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))
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 | 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)
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))
--
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.
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