It's a bit odd that the primary documentation is in notmuch-config,
but it is consistent with the "query:" prefix.

There is a O(log(#user headers)) penalty for the second lookup of the
prefix name.

This should not change the indexing process yet as nothing calls
_notmuch_message_gen_terms with a user prefix name. On the other hand,
it should not break anything either.

This will be used to avoid needing a database access to resolve a db
prefix from the corresponding UI prefix (e.g. when indexing). Arguably
the setup of the seperate header map does not belong here, since it is
about indexing rather than querying, but we currently don't have any
other indexing setup to do.

These tests will need to be updated if the Xapian
query print/debug format changes.

These restrictions are meant to prevent incompatibilities with the
Xapian query parser (which will split at non-word characters) and
clashes with future notmuch builtin fields.

We don't do anything with this configuration information information
yet, but nonetheless add a couple of regression tests to make sure we
don't break standard functionality when we do use the configuration
information.

This will make it easier to add other prefixes that are stored in the
database, compared to special casing each one as "query." was.

This originally use Xapian::Unicode::is_wordchar, but that forces
clients to link directly to libxapian, which seems like it might be
busywork if nothing else.

This should silence some warnings about the jobserver, but also make
it easier to build the docs where GNU make is called something other
than make.

Based on a patch from aidecoe.

Better support build environments where our /sbin/ldconfig based
heuristic does not work (e.g. some musl libc based systems).

Adam Majer pointed out in [1] the way were signing releases was
unusual. Neither Carl nor I could think of a good reason for
explicitely signing the checksum (internally of course that's what GPG
is going anyway).

[1] mid:b3fd556d-c346-7af9-a7a2-13b0f3235071@suse.de

libnotmuch_util.a is supposed to be usable from the library and the
CLI, but much the library is compiled as C++. Add in appropriate
wrapping to prevent symbol mangling. These wrappers already existed in
string-util.h; it seems better to be consistent.

The exact error messages returned by regerror() aren't standardized;
relying on them isn't portable. Thus, add a a prefix to make clear that
the subsequent message is a regexp parsing error, and only look for this
prefix in the test suite, ignoring the rest of the message.

POSIX doesn't specify the flushing behaviour of the STDOUT stream, so
it's invalid to assume a particular order between the stdout and stderr
output. The current test breaks on musl due to this.

In principle we'd like everything to work with ancient versions. In
practice someone needs drive that effort.

Changes from 0.28.3

[dgit --overwrite]

In certain conditions the parallel calls to sphinx-build could
collide, yielding a crash like

Exception occurred:
  File "/usr/lib/python3/dist-packages/sphinx/environment.py", line 1261, in get_doctree
    doctree = pickle.load(f)
EOFError: Ran out of input

I can't figure out how checking the sign of a bool ever worked. The
following program demonstrates the problem (i.e. for me it prints 1).

 #include <stdio.h>
 #include <stdbool.h>
 int main(int argc, char **argv) {
    bool x;
    x = -1;
    printf("x = %d\n", x);
 }

This seems to be mandated by the C99 standard 6.3.1.2.

Because the string_map functions are not exported, we test via message
properties.

In Python bindings, Message.get_property fails with an AttributeError when trying to fetch a property that doesn't exist.

From d712832ba982085975c27b23bb502af82e638b39 Mon Sep 17 00:00:00 2001
From: hydrargyrum <dev@indigo.re>
Date: Sun, 6 Jan 2019 16:08:55 +0100
Subject: [PATCH] python: fix get_property error when property doesn't exist

Using "g" for refresh operations is a pretty common Emacs convention,
codified by `special-mode' in simple.el.

notmuch 0.28.2 release

  * [notmuch-emacs] Invoke gpg from with --batch and --no-tty

[dgit import unpatched notmuch 0.28.2-1]

[dgit import orig notmuch_0.28.2.orig.tar.gz]

[dgit import tarball notmuch 0.28.2-1 notmuch_0.28.2-1.debian.tar.xz]

Indent the directive properly to attach it to Threads autoclass
documentation.

Fixes:

WARNING: don't know which module to import for autodocumenting
'__str__' (try placing a "module" or "currentmodule" directive in the
document, or giving an explicit module name)

Fix documentation build sphinx warning:

filesystem.rst:18: WARNING: Title underline too short.

The simplistic mocking in conf.py falls short on python 3.7. Just use
unittest.mock instead.

Fixes:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/sphinx/config.py", line 368, in eval_config_file
    execfile_(filename, namespace)
  File "/usr/lib/python3/dist-packages/sphinx/util/pycompat.py", line 150, in execfile_
    exec_(code, _globals)
  File "/path/to/notmuch/bindings/python/docs/source/conf.py", line 39, in <module>
    from notmuch import __VERSION__,__AUTHOR__
  File "/path/to/notmuch/bindings/python/notmuch/__init__.py", line 54, in <module>
    from .database import Database
  File "/path/to/notmuch/bindings/python/notmuch/database.py", line 25, in <module>
    from .globals import (
  File "/path/to/notmuch/bindings/python/notmuch/globals.py", line 48, in <module>
    class NotmuchDatabaseS(Structure):
TypeError: __mro_entries__ must return a tuple

When invoking gpg as a backgrounded tool, it's important to let gpg
know that it is backgrounded, to avoid spurious prompts or other
breakage.

In particular, https://bugs.debian.org/913614

 was a regression in
GnuPG which causes problems when importing keys without a terminal,
but gpg expects one.

Ensuring that notmuch-emacs always invokes gpg as a background process
should avoid some of these unnecessary failure.

Thanks to Justus Winter for finding this problem.

Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>