Attempt to distinguish between errors indicating misconfiguration or
programmer error, which we consider "permanent", in the sense that
automatic retries are unlikely to be useful, and those indicating
transient error conditions. We consider XAPIAN_EXCEPTION transient
because it covers the important special case of locking failure.
The idea is to get the mail written to disk, even if we can't open the
database (e.g. because some other process has a write lock, and notmuch
is compiled for non-blocking opens).
Running `gdb command < input` is not as reliable way to give input
to the command (some installations of gdb consume it). Use "set args"
gdb command to have input redirected at gdb 'run' time.
If some software other than notmuch new renames or removes files
during the notmuch new scan (specifically after scandir but before
indexing the file), keep going instead of bailing out. Failing to
index the file is just a race condition between notmuch and the other
software; the rename could happen after the notmuch new scan
anyway. It's not fatal, and we'll catch the renamed files on the next
scan.
Add a new exit code for when files vanished, so the caller has a
chance to detect the race and re-run notmuch new to recover.
Reported by Paul Wise <pabs@debian.org> at
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843127
GnuPG 2.1.16 is now injecting the full issuer fingerprint in its
signatures, which makes them about 32 octets larger when
ascii-armored.
This change in size means that the size of the MIME parts will vary
depending on the version of gpg that the user has installed. at any
rate, the signature part should be non-zero (this is true for
basically any MIME part), so we just test for that instead of an exact
size.
Some of the recent changes to the emacs code have used functions
introduced in emacs 24. The functions used are read-char-choice and
setq-local. This changeset adds a file notmuch-compat.el which
contains compatibility functions so that it should work on emacs
23.
Note, since these functions are taken almost unchanged from the emacs
source they are copyright the Free Software Foundation, and the header
in the file reflects that.
The command notmuch-interesting-buffer has got out of date -- it
doesn't mention notmuch-tree, and it still refers to message-mode not
notmuch-message-mode. Update both of these.
This fixes the bug that notmuch-cycle-notmuch-buffers does not include
notmuch-tree or notmuch-message-mode buffers in its cycling.
This commit expands docstrings for notmuch-fcc-dirs and
notmuch-maildir-fcc-with-notmuch-insert to describe how quoted strings
are processed and make the ability to configure sent folders containing
whitespace more discoverable.
In commit 2a7b11b064 the default value
for notmuch-search-line-faces was changed so that it didn't match the
specification in the corresponding defcustom. This meant that it was
difficult for the user to customize this variable as they got a type
mismatch error.
Note anyone who had already customised this variable would not see
this bug as their customisation would match the defcustom.
This seems to fix a problem with emacs 25 creating partial buttons by
calling n-s-b-l with a region that does not include the whole button.
I'm not 100% sure it's legit to act outside the region passed by
jit-lock, but goto-address-fontify-region (where I borrowed the code
from) already does this, so this patch to not make things worse.
It seems that no-one tried to compile without Xapian compact support
since March of 2015, since that's when I introduced a syntax error in
that branch of the ifdef.
Given the choice of maintaining this underused branch of code, or
bumping the Xapian dependency to a version from 2011, it seems
reasonable to do the latter.
This should not change the SONAME, and therefore won't change the
dynamic linking behaviour, but it may help some users debug missing
symbols in case their libnotmuch is too old.
Since commit
124a67e96e: configure: add set -u
all variables must be set before their expansion are attempted. These
2 variables: "platform" and "linker_resolves_library_dependencies" were
not given value in the final 'else' branch when platform check failed
due to unrecognized kernel name (output of `uname`). Now those two are
given reasonable non-empty values.
