It turns out that putting inline functions in C header files is not a
good idea, and can cause linking problems if the compiler decides not
to inline them. In principle this is solvable by using a "static
inline" declaration, but this potentially makes a copy in every
compilation unit. Since we don't actually care about the performance
of this function, just use a non-inline function.
Starting with Emacs 27 the old `cl' implementation is finally
considered obsolete. Previously its use was strongly discouraged
at run-time but one was still allowed to use it at compile-time.
For the most part the transition is very simple and boils down to
adding the "cl-" prefix to some symbols. A few replacements do not
follow that simple pattern; e.g. `first' is replaced with `car',
even though the alias `cl-first' exists, because the latter is not
idiomatic emacs-lisp.
In a few cases we start using `pcase-let' or `pcase-lambda' instead
of renaming e.g. `first' to `car'. That way we can remind the reader
of the meaning of the various parts of the data that is being
deconstructed.
An obsolete `lexical-let' and a `lexical-let*' are replaced with their
regular variants `let' and `let*' even though we do not at the same
time enable `lexical-binding' for that file. That is the right thing
to do because it does not actually make a difference in those cases
whether lexical bindings are used or not, and because this should be
enabled in a separate commit.
We need to explicitly depend on the `cl-lib' package because Emacs
24.1 and 24.2 lack that library. When using these releases we end
up using the backport from GNU Elpa.
We need to explicitly require the `pcase' library because
`pcase-dolist' was not autoloaded until Emacs 25.1.
This test extracts values from a (key,value) map where multiple entries
can have the same key, and the entries are sorted by key, but not by
value. The test incorrectly assumes that the values will be sorted as
well, so sort the output.
Xapian 1.4 is over 3 years old now (1.4.0 released 2016-06-24),
and 1.2 has been deprecated in Notmuch version 0.27 (2018-06-13).
Xapian 1.4 supports compaction, field processors and retry locking;
conditionals checking compaction and field processors were removed
but user may want to disable retry locking at configure time so it
is kept.
Context: I am compiling notmuch on OpenBSD which has a rather old zlib
1.2.3. It seems that the behaviour of gzgets() changed slightly between
this version and more recent versions, but the manual does not reflect
that change. Note that zlib's manual:
- does not specify which error code (Z_OK or Z_STREAM_END) is set when
EOF is reached,
- does not indicate the meaning of Z_STREAM_END after gzgets(), but
based on its meaning as a possible return value of inflate(), I would
guess that it means EOF.
amended by db: tidy commit message
This is the non-deprecated way to use completing-read. Additionally
the old use was broken when using ivy for completing-read. For user's
using completing-read-default they won't see the default URL now, but
if they hit enter it will be visited. Alternatively they can select
it with M-n.
From the completing-read documentation for initial-input:
This feature is deprecated--it is best to pass nil for INITIAL-INPUT
and supply the default value DEF instead. The user can yank the
default value into the minibuffer easily using M-n.
Additionally collection is now all urls, rather than all but the
first. I'm not sure why "(cdr urls)" was previously done.
This is like notmuch-search-filter-by-tag, but creates a new search
rather than filtering the current search. We add this to
notmuch-common-keymap since this can be used by many contexts. We bind
to the key "t", which is the same key used by
notmuch-search-filter-by-tag in notmuch-search-mode-map. This is done
intentionally since the keybinding for notmuch-search-mode-map can be
seen as a specialization of creating a new search.
This change was motivated for use in "notmuch-hello". It is a more
convenient way to search a tag than expanding the list of all tags. I
also noticed many saved searches people use are simply tags.
'qsx' reported a bug on #notmuch with notmuch-dump and large stored
queries. This test will pass (on my machine) if the value of `repeat'
is made smaller.
Reported-By: Thomas Schneider <qsx@chaotikum.eu>
Add x and X binds to notmuch-tree for functionally that we have in
notmuch-show.
The notmuch-tree-quit binding is somewhat redundant, since it is
handled by notmuch-bury-or-kill-this-buffer which is bound to q.
Signed-off-by: William Casarin <jb55@jb55.com>
This functions removes some duplicate logic between
notmuch-tree-{next,prev}-matching-message
We do this because we will be adding some additional logic similar to
the notmuch-show-next-open-message function, and it will help if this
logic is all in one place.
Signed-off-by: William Casarin <jb55@jb55.com>
This function captures some common logic when jumping to matching
messages in notmuch-tree mode.
We also add a new return value (t or nil), that indicates if there was
a next matching message in the thread to show.
Signed-off-by: William Casarin <jb55@jb55.com>
nmbug and notmuch-report are developer tools. It's 2018, and all
developers should have python3 available.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Ship a new debian package for the notmuch2 CFFI-based Python interface
to notmuch.
Unlike the notmuch python module, the new notmuch2 module is no longer
arch-independent, because it builds and ships a shared object in
addition to the python code.
This patch encourages new downstream development to rely on notmuch2
instead of on notmuch, to get the benefits of the new module.
I welcome any suggested improvements to this packaging, but it appears
to me to be sufficient to get "import notmuch2" to work and do some
basic tests.
Since doxygen 1.8.16, MSCGEN_PATH and PERL_PATH are obsolete:
MSCGEN_PATH:
873e0ccfbe
PERL_PATH:
6d1535c38f
I don't think that the notmuch builds ever depended on them in the
first place, and including them in the default config yields the
following two warnings:
```
doxygen ./doc/doxygen.cfg
warning: Tag 'PERL_PATH' at line 267 of file './doc/doxygen.cfg' has become obsolete.
To avoid this warning please remove this line from your configuration file or upgrade it using "doxygen -u"
warning: Tag 'MSCGEN_PATH' at line 272 of file './doc/doxygen.cfg' has become obsolete.
To avoid this warning please remove this line from your configuration file or upgrade it using "doxygen -u"
```
Remove them to avoid the warnings.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
The -D flag to install (used in the Makefile) is GNU-specific and does
not work on BSD distributions (i.e. macOS). Likewise with the xargs -r
flag. These changes use portable alternatives to these flags while
preserving the exact behavior.
Without this change, we see the following warning when compiling the
elisp:
```
EMACS emacs/notmuch-crypto.elc
In end of data:
emacs/notmuch-crypto.el:266:1:Warning: the function
‘notmuch-show-get-message-id’ is not known to be defined.
```
Thanks to Örjan Ekeberg and David Edmondson for their followup about
this.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Avoid a memory leak in the notmuch command line.
gmime_multipart_encrypted_decrypt returns a GMimeObject marked by
GMime as "transfer full", so we are supposed to clean up after it.
When parsing a message, notmuch would leak one GMimeObject part per
multipart/encrypted MIME layer. We clean it up by analogy with
cleaning up the signature list associated with a MIME node.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
When walking the MIME tree, we might need to extract a new MIME
object. Thus far, we've only done it when decrypting
multipart/encrypted messages, but PKCS#7 (RFC 8551, S/MIME) has
several other transformations that warrant a comparable form of
unwrapping.
Make this member re-usable for PKCS#7 unwrappings as well as
multipart/encrypted decryptions.
This change is just a naming change, it has no effect on function.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Saved searches in notmuch-hello and notmuch-jump can specify whether
to use search mode or tree mode. This adds an option for them to
specify unthreaded mode.
We have shortcuts S and Z to let the user switch to Search view and
Tree view with the current search. Add U to let the user switch to
unthreaded view from the current search, and ensure that S and Z
switch from unthreaded to search and tree veiew respectively.
Tree mode allows the user to choose whether to use the split screen
displaying just the current message or a full screen displaying the
entire thread. As unthreaded mode is quite different in use the user
may want a different customisation for this mode.
It is likely that the user will want a different line format for
unthreaded mode from tree mode; in particular the thread structure
graphics are unnecessary in unthreaded mode.
Add a new customisable variable and set it to something sensible.
This commit introduces a new 'unthreaded' search mode where each
matching message is shown on a separate line. It shares almost all of
its code with tree view. Subsequent commits will allow it to diverge
slightly in appearance.
This adds a --unthreaded option to notmuch show to tell it to return
the matching messages in an unthreaded order (so just by date).
To make it easier for users, in particular for notmuch-tree.el, we
output each message with the same "nesting" as if it were an entire
thread in its own right.
amended by db: s/status= /status = /
Apparently doxygen needs its comments formatted in a specific way to
notice that the group is closed.
Without this fix, with doxygen 1.8.16-2 we see:
```
doxygen ./doc/doxygen.cfg
…/notmuch/lib/notmuch.h:2322: warning: end of file while inside a group
```
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
GMIME_ENCRYPT_NONE and GMIME_VERIFY_NONE have the same value, but they
are different enumerated types. So in C, this is a cosmetic change,
but it is technically correct if we only had stricter typing.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
crypto.gpg_path was only used when we built against gmime versions
before 3.0. Since we now depend on gmime 3.0.3 or later, it is
meaningless.
The removal of the field from the _notmuch_config struct would be an
ABI change if that struct were externally exposed, but it is not, so
it's safe to unilaterally remove it.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
In particular, timestamps beyond 2038 could overflow the sprinter
interface on systems where time_t is 64-bit but 'int' is a signed 32-bit
integer type.
The escaping in the description of the output of "notmuch-config list"
appears to have been inherited from some previous attempts at
documentation. It leaked out in the actual generated manpage
documentation, where it looks like this:
list Every configuration item is printed to stdout, each on a
separate line of the form:
*section*.\ *item*\ =\ *value*
This simplification cleans up the overescaping.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
See lintian informational tag
symbols-file-missing-build-depends-package-field for hints about this
minor metadata update.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
It causes this function to fail with:
let: Wrong type argument: null, t
Support for this was removed from Emacs in April
2019 (5c5e309527e6b582e2c04b83e7af45f3144863ac) because it never
worked correctly (apparently).
This also shouldn't be necessary as sentinels will not be called
unless emacs is idle or waiting for input. Therefore, the
`process-put' calls immediately following the `make-process' call
should always complete before the sentinel is first called.
These tests were an attempt to establish that the content of the
"Legacy Display" part is the same as the actual protected headers of
the message. But this is more conservative than we need to be.
https://www.ietf.org/id/draft-autocrypt-lamps-protected-headers-02.html
section 5.3 makes clear that the Legacy Display part is purely
decorative, and section 5.2.1 clarifies that the detection can be done
purely by MIME structure and Content-Type alone.
Furthermore, now that we're accepting text/plain Legacy Display parts,
it's not clear the lines in the Legacy Display part should be
interpreted as needing an exact string match (e.g. "real" headers are
likely to be RFC 2047 encoded, but the text/plain Legacy Display part
probably should not be).
The concerns that motivated this test in the past were twofold: that
we might accidentally hide some information from the reader of the
message that they should have available to them, or that we could
introduce a covert channel that would be invisible to other clients.
I no longer think these are significant concerns:
a) There will be no accidental misidentification of a Legacy Display
part. The identification of the Legacy Display part is
unambiguous due to MIME structure and Content-Type. MIME
structure MUST be the first child part of a two-part
multipart/mixed Cryptographic Payload. And the
protected-headers=v1 content-type parameter must be present on
both the cryptographic payload and the legacy display part, so no
one would accidentally generate this structure and have it be
accidentally matched.
b) As for creating a covert channel, many such channels already
exist. For example, non-standard e-mail headers, custom MIME
types, unusual MIME structures, etc, all make it possible to ship
some content in a message that will be visible in some MUAs but
not in others. This doesn't make the situation demonstrably
worse.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
https://www.ietf.org/id/draft-autocrypt-lamps-protected-headers-02.html
Makes it clear that the "Legacy Display" part of an encrypted message
with protected headers can (and indeed, should) be of content-type
text/plain, though some clients still generate the Legacy Display part
as content-type text/rfc822-headers. Notmuch should recognize the
part whichever of the two content-types it uses.
See also discussion in
https://github.com/autocrypt/protected-headers/issues/23 for why the
community of implementers is moving in the direction of text/plain.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
