Mark Walters writes:
> Formerly replying to an encrypted message in tree-view did not
> work. This is a first attempt to make it work.
> ---
>
> notmuch-mua-reply decides whether to process crypto based on the
> buffer-local variable notmuch-show-process-crypto. This sets to its
> default value (
dm-list-email-notm...@scs.stanford.edu writes:
> It seems that disabling it should simply be safe. But re-enabling, one
> risks losing tags, as the next notmuch new will cause old maildir flags
> to override the xapian database. So that suggests something like:
>
>notmuch dump > backup
>
David Bremner writes:
> dm-list-email-notm...@scs.stanford.edu writes:
>
>> It seems that disabling it should simply be safe. But re-enabling, one
>> risks losing tags, as the next notmuch new will cause old maildir flags
>> to override the xapian database. So that suggests something like:
>>
>
Tomi Ollila writes:
> Now I took a little better look why the 'relative' date is not enough for
> me is that it doesn't always show the local date (it shows like
> (28 mins. ago) or (March 30)). If these were (28 mins. ago (07:22)) and
> (March 30 16:20) then it would be better (w/ +0300 that mi
David Mazieres writes:
> So my question remains, what's the easiest safe way to re-enable
> synchronize_flags after disabling it? (Safe meaning it won't change any
> tags.) It could be that there's a very simple answer, in which case
> sticking it in the man page might be nice.
I can't think
It's becoming a maintenance burden to do anything things with the
crypto glue code twice, once for 2.4 and once for 2.6. I don't have
any 2.4 version available to test on my development machine anymore,
so the 2.4 specific code paths are likely not very well tested.
---
I started to rebase the SMI
---
notmuch-client.h | 18 +-
1 file changed, 1 insertion(+), 17 deletions(-)
diff --git a/notmuch-client.h b/notmuch-client.h
index 78680aa..1f82656 100644
--- a/notmuch-client.h
+++ b/notmuch-client.h
@@ -30,16 +30,7 @@
#include
-/* GMIME_CHECK_VERSION in gmime 2.4 is not
It turns out S/MIME encryption requires non-trivial additional code in
libgmime. There is no reason to wait for that to support signtures (via
emacs+openssl|epg), and verification (via notmuch-cli).
Here we also test encryption, relying on emacs message-mode facilities.
(At least) two things co
The test is pretty much cut and paste from the PGP/MIME version, with
obvious updates taken from notmuch output. This also requires setting
up gpgsm infrastucture.
---
test/T355-smime.sh | 50 ++
test/test-lib.sh | 1 +
2 files changed, 51 insert
It's not needed for the actual build, but it is needed to run
the SMIME tests.
---
debian/control | 1 +
1 file changed, 1 insertion(+)
diff --git a/debian/control b/debian/control
index 05cd04f..37ecedd 100644
--- a/debian/control
+++ b/debian/control
@@ -22,6 +22,7 @@ Build-Depends:
emacs23-n
From: Jani Nikula
Let the context creation functions decide how to handle multiple calls
and cache the crypto context. No functional changes.
---
crypto.c | 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/crypto.c b/crypto.c
index a6eb27d..1187ad7 100644
--
From: Jameson Graef Rollins
---
debian/control | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/debian/control b/debian/control
index 4bc4cd9..05cd04f 100644
--- a/debian/control
+++ b/debian/control
@@ -31,7 +31,7 @@ Vcs-Browser: http://git.notmuchmail.org/git/notmuch
Packag
From: Jani Nikula
notmuch-show --verify will now also process S/MIME multiparts if
encountered. Requires gmime-2.6 and gpgsm.
Based on work by Jameson Graef Rollins .
---
crypto.c | 50 ++
notmuch-client.h | 7 +--
test/T355-smime
From: Jani Nikula
The current error message is not helpful.
---
crypto.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/crypto.c b/crypto.c
index f415abd..11c167e 100644
--- a/crypto.c
+++ b/crypto.c
@@ -67,7 +67,8 @@ notmuch_crypto_get_context (notmuch_crypto_t *crypto, c
From: Jani Nikula
Make it trivial to add handlers for new protocols without duplicating
code. No functional changes.
---
crypto.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/crypto.c b/crypto.c
index 1187ad7..f415abd 100644
--- a/crypto.c
+++ b/crypto.c
@@ -
David Bremner writes:
> David Mazieres writes:
>> So my question remains, what's the easiest safe way to re-enable
[ 2 more citation lines. Click/Enter to show. ]
>> synchronize_flags after disabling it? (Safe meaning it won't change any
>> tags.) It could be that there's a very simple answer,
On Sun, Aug 16 2015, David Bremner wrote:
> Tomi Ollila writes:
>
>> Now I took a little better look why the 'relative' date is not enough for
>> me is that it doesn't always show the local date (it shows like
>> (28 mins. ago) or (March 30)). If these were (28 mins. ago (07:22)) and
>> (March
On Sun, Aug 16 2015, David Bremner wrote:
> It's becoming a maintenance burden to do anything things with the
> crypto glue code twice, once for 2.4 and once for 2.6. I don't have
> any 2.4 version available to test on my development machine anymore,
> so the 2.4 specific code paths are likely no
I'm pleased to announce the release of muchsync version 2. Muchsync is
a tool for replicating and synchronizing your notmuch databases across
machines.
The new version is reported to build out of the box on Mac OS X.
There's one new feature, which is a new notmuch config option,
"muchsync.and_ta
Mark Walters writes:
> Formerly replying to an encrypted message in tree-view did not
> work. This is a first attempt to make it work.
> ---
>
> notmuch-mua-reply decides whether to process crypto based on the
> buffer-local variable notmuch-show-process-crypto. This sets to its
> default value (
dm-list-email-notmuch at scs.stanford.edu writes:
> It seems that disabling it should simply be safe. But re-enabling, one
> risks losing tags, as the next notmuch new will cause old maildir flags
> to override the xapian database. So that suggests something like:
>
>notmuch dump > backup
>
David Bremner writes:
> dm-list-email-notmuch at scs.stanford.edu writes:
>
>> It seems that disabling it should simply be safe. But re-enabling, one
>> risks losing tags, as the next notmuch new will cause old maildir flags
>> to override the xapian database. So that suggests something like:
>
Tomi Ollila writes:
> Now I took a little better look why the 'relative' date is not enough for
> me is that it doesn't always show the local date (it shows like
> (28 mins. ago) or (March 30)). If these were (28 mins. ago (07:22)) and
> (March 30 16:20) then it would be better (w/ +0300 that mi
Test the ability of notmuch-mua-mail to send S/MIME signed (and
encrypted) messages; this really relies on existing functionality in
message-mode.
The dependency on openssl to generate keys seems acceptable since
that's the method I got to work for smime signing in emacs.
The generated keys and m
24 matches
Mail list logo