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:
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.
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.♥
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.
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 can change how mu4e does it in the same commit since it has the
same format.
---
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.
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.
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 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:
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'.
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")
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.
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.