| Age | Commit message (Collapse) | Author |
|---|
|
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).
|
|
Testing will be provided via use in notmuch_message_reindex
|
|
The structured output formats already have all of the filenames. This
is an easy bit of UI change to make the multiple files visible.
|
|
This is relatively inexpensive in terms of run time and implementation
cost as we are already traversing the list of messages in a thread.
|
|
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.
|
|
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 function is large and hard to understand and modify. Start to
break it down into meaningful pieces.
|
|
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.
|
|
uploaded to unstable
|
|
- build against gmime 3.0 by preference
- drop gmime-2.4-dev, no longer supported upstream
|
|
notmuch Debian 0.25-1 upload (same as 0.25)
|
|
|
|
|
|
|
|
These are from Tomi, split from the previous commit
|
|
|
|
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.
|
|
|
|
|
|
|
|
It's a bit crazy to require emacs 24 installed just to build, when it
isn't required to run.
|
|
This is needed for consistent beheviour between notmuch built against
gmime-2.6 and gmime-3.0 w.r.t. error reporting.
|
|
|
|
|
|
|
|
|
|
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
|
|
Resolves lintian binary-control-field-duplicates-source
|
|
This actually happened in 0.24.x.
|
|
merge 32 bit compilation fix
|
|
|
|
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.
|
|
|
|
notmuch 0.25~rc0 release
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
based on the same patch from dkg as the previous commit.
|
|
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)
|
|
These are due to (excessively?) fancy macro definitions in gmime-extra.h
|
