test: add missing quotes in maildir-sync test.

Oops. ';' is significant in the shell. Who knew.

Merge branch 'release'

merge in debian-only changes

cli/new: improve error reporting

Recently a user reported a crash in notmuch new, but because of
missing error reporting, all they could say was "A Xapian exception
occured". This commit adds the extra information available about
the error message in the exception.

debian: start changelog for next debian upload

do not use bullets in debian/NEWS

see lintian's debian-news-entry-uses-asterisk for justification

remove obsolete lintian-override (see https://bugs.debian.org/865055)

Merge tag 'debian/0.25-6'

uploaded to unstable

debian: actually stop shipping 50notmuch.el

Merge tag 'debian/0.25-5'

uploaded to unstable

debian upload 0.25-5

fix typo in -4

test: add broken tests for maildir syncing

Users should be able to specify synced tags in new.tags

Merge tag 'debian/0.25-4'

uploaded to unstable

debian: upload 0.25-4

replace notmuch-emacs with elpa-emacs as a recommend

Merge tag 'debian/0.25-3'

uploaded to unstable

debian: changelog stanza for 0.25-3

debian: add maintainer scripts to remove old startup file

We do it for notmuch and notmuch-emacs because the history is a bit
unclear. It seems to be safe to call when that conffile is not owned
by a given package

add "notmuch reindex" subcommand

This new subcommand takes a set of search terms, and re-indexes the
list of matching messages.

lib: add notmuch_message_reindex

This new function asks the database to reindex a given message.
The parameter `indexopts` is currently ignored, but is intended to
provide an extensible API to support e.g. changing the encryption or
filtering status (e.g. whether and how certain non-plaintext parts are
indexed).

lib: add _notmuch_message_remove_indexed_terms

Testing will be provided via use in notmuch_message_reindex

cli/search: print total number of files matched in summary output.

The structured output formats already have all of the filenames. This
is an easy bit of UI change to make the multiple files visible.

lib: add notmuch_thread_get_total_files

This is relatively inexpensive in terms of run time and implementation
cost as we are already traversing the list of messages in a thread.

lib: add notmuch_message_count_files

This operation is relatively inexpensive, as the needed metadata is
already computed by our lazy metadata fetching. The goal is to support
better UI for messages with multipile files.

lib: index message files with duplicate message-ids

The corresponding xapian document just gets more terms added to it,
but this doesn't seem to break anything. Values on the other hand get
overwritten, which is a bit annoying, but arguably it is not worse to
take the values (from, subject, date) from the last file indexed
rather than the first.

test: add known broken tests for duplicate message id

There are many other problems that could be tested, but these ones we
have some hope of fixing because it doesn't require UI changes, just
indexing changes.

lib: refactor notmuch_database_add_message header parsing

This function is large and hard to understand and modify. Start to
break it down into meaningful pieces.

lib: factor out message-id parsing to separate file.

This is really pure C string parsing, and doesn't need to be mixed in
with the Xapian/C++ layer. Although not strictly necessary, it also
makes it a bit more natural to call _parse_message_id from multiple
compilation units.

lib/n_d_add_message: refactor test for new/ghost messages

The switch is easier to understand than the side effects in the if
test. It also potentially allows us more flexibility in breaking up
this function into smaller pieces, since passing private_status around
is icky.

lib: isolate n_d_add_message and helper functions into own file

'database.cc' is becoming a monster, and it's hard to follow what the
various static functions are used for. It turns out that about 1/3 of
this file notmuch_database_add_message and helper functions not used
by any other function. This commit isolates this code into it's own
file.

Some side effects of this refactoring:

- find_doc_ids becomes the non-static (but still private)
  _notmuch_database_find_doc_ids
- a few instances of 'string' have 'std::' prepended, avoiding the
  need for 'using namespace std;' in the new file.

Merge tag 'debian/0.25-2'

uploaded to unstable

debian: update gmime dependencies

- build against gmime 3.0 by preference
- drop gmime-2.4-dev, no longer supported upstream

Merge tag 'debian/0.25-1'

notmuch Debian 0.25-1 upload (same as 0.25)

debian: add changelog entry for 0.25

NEWS: set date

version: bump to 0.25

NEWS: formatting fixups

These are from Tomi, split from the previous commit

NEWS for release 0.25: Emacs: support for stashing message timestamp

emacs: Add commentary for MELPA users

We have a steady trickle of people using notmuch-emacs from melpa with
distro packages of notmuch, and then being confused when it doesn't
work. Try to warn people what a foot-gun this is; this commentary
should be copied to the melpa web site.

debian: changelog for 0.25~rc1-2

debian: finalize changelog for 0.25~rc1-1

version: bump to 0.25~rc1

debian: allow emacs25 as a build depend

It's a bit crazy to require emacs 24 installed just to build, when it
isn't required to run.

emacs: convert remaining format-versions from 3 to 4

This is needed for consistent beheviour between notmuch built against
gmime-2.6 and gmime-3.0 w.r.t. error reporting.

fix the generated documentation output

Fix orthography

use modern debian/copyright

avoid false lintian warning about "iff"

resolve lintian tag debhelper-but-no-misc-depends notmuch-emacs

This is likely not strictly necessary given that notmuch-emacs is a
transitional package.  But having a simple consistency until we
eventually remove the transitional notmuch-emacs package seems ok too,
and fewer arbitrary lintian warnings will make real lintian warnings
more visible.

fix Python capitalization

explicitly mark notmuch-emacs as transitional

Bump standards version to 4.0.0 (no changes needed)

Some things that might be interesting (and are acceptable and
supported under 4.0.0, though not required) are:

 * supporting DEB_BUILD_OPTIONS tag nodoc wihle tagging build-deps (we
   could put python-sphinx into <!nodoc>, for example)

 * splitting out Build-Depends-Arch from Build-Depends

Drop duplicate Section header for notmuch-vim

Resolves lintian binary-control-field-duplicates-source

NEWS: drop redundant mention of dump fix

This actually happened in 0.24.x.

Merge tag 'debian/0.25_rc0-2'

merge 32 bit compilation fix

debian: changelog stanza for 0.25~rc0-2

util: make g_mime_utils_header_decode_date_unix match prototype

The problem shows up on 32 bit architectures where sizeof(time_t) !=
sizeof(gint64).  Upcasting the 32 bit time_t to a 64 bit integer
should hopefully be safe.

NEWS: Initial writeup for my contributions to 0.25

Merge tag '0.25_rc0'

notmuch 0.25~rc0 release

debian: note two closed bugs in changelog

debian: don't create obsolete bash completion dir

debian: set distribution to experimental, finalize changelog

debian: add more c++ gunk to symbols file

debian: bump changelog version, mention SONAME bump

NEWS: start entry for 0.25

version: bump version to 0.25~rc0

crypto: clean up unused definitions in gmime 3.0

based on the same patch from dkg as the previous commit.

crypto: Avoid explicit handling of GMimeCryptoContext in gmime 3

gmime 3.0 knows how to select the correct GMimeCryptoContext
automatically, so a bunch of the code in notmuch can be dropped in
that case.

The #ifdef removal of the crypto stuff is better than #define aliasing
in gmime-extra.h for this stuff.  When built against gmime 3.0:

    * it reduces compiled code, and
    * it avoids initializing unused gpgme contexts

(based on a patch from dkg)

cli/crypto: eliminated compiler warnings about unused arguments

These are due to (excessively?) fancy macro definitions in gmime-extra.h

cli/crypto: treat failure to create a crypto context as fatal.

Silently ignoring signed/encrypted parts seems like the wrong idea,
and it also complicates future gmime-3.0 compatibility changes.

emacs: change default for notmuch-crypto-process-mime to t

There are some cases like remote usage where this might cause
problems, but those users can easily customize the variable. The
inconvenience seems to be outweighed by the security benefit for most
users.

NEWS: a few formatting updates for 0.24 news items (wiki compatibility)

- removed 7 trailing dots -- to make those lines subsection headers

- converted some (mime type) text to monospace

- removed one extra space

clean up use of constants in g_mime_multipart_ wrappers

When compiling as C code (instead of C++) against gmime 3.0, gcc gives
errors like the following:

    error: invalid conversion from ‘int’ to ‘GMimeDecryptFlags’ [-fpermissive]

so use explicit *_NONE values instead.

config: deprecate/drop crypto.gpg_path under gmime 2.6/3.0

gmime 3.0 no longer offers a means to set the path for gpg.

Users can set $PATH anyway if they want to pick a
differently-installed gpg (e.g. /usr/local/bin/gpg), so this isn't
much of a reduction in functionality.

The one main difference is for people who have tried to use "gpg2" to
make use of gpg 2.1, but that isn't usefully co-installable anyway.

Add additional munged reply-to tests

The reply-to munging code might behave differently whether there's an
exact match on the strings or not, or whether the string is a raw
addr-spec instead of an name-addr.  These tests cover those variations
(i also had to tweak json output further below when this new test was
added).

Ensure that "notmuch reply" succeeds during testing.

In some (bad!) cases, "notmuch reply" might fail, or might even
segfault.  If this happens, it indicates a bug, and the test suite
should notice it.

cli: wrap getting uid

Apparently it moved from "name" to "key_id" in gmime-3.0

cli: make keyid from fingerprint in gmime 3.0

The "key_id" field seems to used for userid in gmime-3.0, while the
keyid is dropped in the fingerprint field if the full fingerprint is
not available.

lib: paper over allocation difference

In gmime 3.0 this function is "transfer none", so no deallocation is
needed (or permitted)

lib: add version of _n_m_f_get_combinded_header for gmime 3.0

The iterator is gone, so we need a new loop structure.

lib: refactor _notmuch_messsage_file_get_combined_header

We need to rewrite the loop for gmime-3.0; move the loop body to its
own function to avoid code duplication.  Keep the common exit via
"goto DONE" to make this pure code movement.  It's important to note
that the existing exit path only deallocates the iterator.

lib: wrap use of g_mime_utils_header_decode_date

This changes return type in gmime 3.0

cli: hide rename of GMimeCertificateTrust

Both the enum and the values are renamed in GMime 3.0.

cli: generalize use of GMIME_SIGNATURE_{ERROR,STATUS} to gmime-3

The ERROR enum is merged into to the STATUS enum, and the set of flags
is different.

util: fake gmime-2.6 compatible API for gmime-3.0

Several functions have added arguments which accept NULL and provide
hopefully sensible defaults. Use macros to minimize source changes.

cli: replace use of g_mime_message_get_recipients

This function, and associated enum, have been renamed and generalized
in gmime-3.0.

lib/cli: replace use of g_mime_message_get_sender

This function changes semantics in gmime-3.0 so make a new function
that provides the same functionality in both

cli: replace use of g_mime_message_get_reply_to

This function changes signature in gmime 3.0, so we provide two new
functions, one for each signature.

cli: replace use of g_mime_message_get_date_as_string

This function goes away in gmime-3.0. Also, the memory management is
apparently error prone, witness the memory leak in notmuch-reply.

test/crypto: mark extra space in userid as a bug in gmime-2.6

I can't see the space in the output of gpg -K --with-colons

cli: add space separator for keyword, string, and int arguments

Defer the complication of optional boolean arguments for later (never?).

cli: change api of parse_option

The idea is to allow it (in a future commit) advance to the next argv
element to get a value

cli/show: convert keyword options to booleans

There are two keyword options here that impliment boolean options. It
is simpler to use the built-in boolean argument handling, and also
more robust against divergence in parsing boolean and keyword arguments.

emacs: tree: drop repeated "of" from docstring

debian: drop notmuch-dbg

notmuch-dbgsym should be auto generated now.

test/crypto: add test for corrupted signatures

Have an empty list of signatures is not the nicest mechanism to signal
complete failure to verify, but it's the one we currently have.

test: add test for modified pgp/mime signed message

This is a good thing to test in any case, but particularly as we hit
the dark corners of the gmime crypto API.

test: mark test as broken in gmime 3.0

Currently I'm not sure what the intent of this test is, so it's not
clear if the new answer is better or worse than the old one.

test: mark inclusion of headers as broken in gmime-2.x

The output of headers here reflects an underlying bug / quirk of
gmime-2.6.

test/multipart: reorganize creation of multipart message

We want to have the bodies of the multipart available in a file on
their own for planned modifications to tests.

cli: implement structured output version 4

Since the error field is unused by the emacs front end, no changes are
needed other than bumping the format version number.

As it is, this is a bit overengineered, but it will reduce duplication
when we support gmime 3.0

devel/schemata: describe version 4

Replace numeric errors with human readable flags.  Not all sig_error
keys will necessarily be generated with a given version of gmime.

Drop status "none" as it's currrently unused and I don't know what
it's for.