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.
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.
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.
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.
'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.
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.
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.
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
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.
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)
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.
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.
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.
