If a test has added a GnuPG homedir, it may well want to know the
fingerprint. This saves us from having to redefine this magic string
in multiple places when more tests evenutally use the GnuPG homedir.
---
test/T350-crypto.sh | 2 --
test/test-lib.sh| 3 +++
2 files changed, 3
This makes it easier to reuse format_part_sigstatus_sprinter() when we
have other places that we want to display a signature status.
---
notmuch-show.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/notmuch-show.c b/notmuch-show.c
index 07e9a5db..88699e90 100644
---
Unsigned encrypted mail shows up with a weird empty signature list.
If we successfully decrypted and there was no signature in it, we
should just not show a sigstatus at all.
The documentation for g_mime_decrypt_result_get_signatures says:
a GMimeSignatureList or NULL if the stream was not
Ralph Seichter writes:
> * Eric:
>
>> I think that there will be lots of people (and organisations) who get
>> collections of email from elsewhere and want to add them all to their
>> own single collection for reference, archival, and research purposes.
>
> And how would dropping individual mail
* David Bremner:
> Right, I think that point is clear now, that we're just talking about
> changing the warning messages.
Indeed. I am actually quite surprised how many reactions there were
about this minor issue. I'm using the new.ignore settings you suggested,
and I can live with that. The
On Sat, 20 Apr 2019 01:46:30 +0200, Ralph Seichter
wrote:
> * Daniel Kahn Gillmor:
>
> > as far as maildir goes, i think notmuch probably *shouldn't* be
> > looking at stuff in â¦/tmp/ -- right?
>
> You're right, I don't see why Notmuch would peek into "tmp".
>
> > I'd be sad if those files
Looks good. Sorry for missing this.
On Friday, 2019-04-19 at 10:56:59 +07, Doan Tran Cong Danh wrote:
> From notmuch 0.28, notmuch support relative database path in
> notmuch-config(1), but python binding haven't taught this yet.
>
> afew denied to work with a perfectly fine notmuch-config due
* Eric:
> I think that there will be lots of people (and organisations) who get
> collections of email from elsewhere and want to add them all to their
> own single collection for reference, archival, and research purposes.
And how would dropping individual mail files into "cur" instead of any
Without this change, we see the following warnings during the build:
```
In toplevel form:
emacs/notmuch-mua.el:119:1:Warning: defcustom for
‘notmuch-mua-attachment-regexp’ fails to specify type
emacs/notmuch-mua.el:119:1:Warning: defcustom for
‘notmuch-mua-attachment-regexp’ fails to
When i'm building notmuch in a debian environment with emacs
1:26.1+1-3.2, i notice the following deprecation warnings:
In notmuch-maildir-setup-message-for-saving:
emacs/notmuch-maildir-fcc.el:172:31:Warning: ‘message-default-charset’ is an
obsolete variable (as of 26.1); The default charset
Hi folks--
when i run "make" from my source tree, and it succeeds, i typically
expect that running "make" again will show that nothing needs to be
done.
but that's not the case. Both the sphinx-based documentation and the
ruby notmuch.so are always rebuilt, i think due to some sort of
On a system where man and notmuch are both already installed, i tried to
./configure --without-docs to avoid the delays during development
associated with id:87r29wwgq2@fifthhorseman.net.
The configuration succeeds, but now these tests fail:
0 dkg@alice:~/src/notmuch/notmuch$ make check
Daniel Kahn Gillmor writes:
> Hi folks--
>
> when i run "make" from my source tree, and it succeeds, i typically
> expect that running "make" again will show that nothing needs to be
> done.
>
> but that's not the case. Both the sphinx-based documentation and the
> ruby notmuch.so are always
13 matches
Mail list logo
