As recently discussed on the mailing list. See, for example: id:"firstname.lastname@example.org"
Theses were expected failures only due to a bug in GMime (with versions of GMime before 2.4.18). As of GMime version 2.4.18 this bug is fixed and these tests now pass.
This enables the proper face customization UI for notmuch-search-line-faces.
Now each caller of notmuch_message_get_tags only gets a new iterator, instead of a whole new list. In principle this could cause problems with iterating while modifying tags, but through the magic of talloc references, we keep the old tag list alive even after the cache in the message object is invalidated. This reduces my index search from the 3.102 seconds before the unified metadata pass to 1.811 seconds (1.7X faster). Combined with the thread search optimization in b3caef1, that makes this query 2.5X faster than when I started.
Even if the caller never uses the file names, there is little cost to simply fetching the file name terms. However, retrieving the full paths requires additional database work, so the expansion from terms to full paths is performed lazily. This also simplifies clearing the filename cache, since that's now handled by the generic metadata cache code. This further reduces my inbox search from 3.102 seconds before the unified metadata pass to 2.206 seconds (1.4X faster).
Replace _notmuch_convert_tags with this and simplify _create_filenames_for_terms_with_prefix. This will also come in handy shortly to get the message file name list.
This replaces the guts of the filename list and tag list, making those interfaces simple iterators over the generic string list. The directory, message filename, and tags-related code now build generic string lists and then wraps them in specific iterators. The real wins come in later patches, when we use these for even more generic functionality. As a nice side-effect, this also eliminates the annoying dependency on GList in the tag list.
This performs a single pass over a message's term list to fetch the thread ID, message ID, and reply-to, rather than requiring a pass for each. Xapian decompresses the term list anew for each iteration, so this reduces the amount of time spent decompressing message metadata. This reduces my inbox search from 3.102 seconds to 2.555 seconds (1.2X faster).
To avoid a wraning about a reference to a free variable when compiling.
With the previous commit, unexpected output before or between search results would be displayed. However, trailing junk from the "notmuch search" output would still be silently swallowed. The most common case for an error message from "notmuch search" would be an invalid command-line, and in that case, there would be no search results and the trailing error message would get swallowed. We fix the process sentinel to check for leftover data and add it to the final buffer. We also add a test case to ensure this works.
This fixes the recently-added emacs-large-search-buffer test. This is as simple as saving any trailing input and then pre-prepending it on the next call. MAny thanks to Thomas Schwinge <email@example.com> for tracking down this problem and contributing a preliminary version of this fix.
Rather than silently swallowing unexpected output, the emacs interface will now display it. This will allow error messages to actually arrive at the emacs interface (though not in an especially pretty way). This also allows for easier investigation of the inadvertent swallowing of search results that span page boundaries (as demonstrated by the recent added emacs-large-search-buffer test). The page-boundary bug has been present since a commit from 2009-11-24: 93af7b5 Many thanks to Thomas Schwinge for tracking that bug down and contributing the test for it.
…h-buffer) The new name is more descriptive of the bug being tested. Also, the test is rewritten slightly so that it's much more plain to see how the bug manifests itself, (that messages are droped from the emacs result at regular intervals). Primarily, this is by collapsing the large blobs used to inflate the message subjects.
The db_files and db_subdirs are unnecessary for unchanged directories. maildir with 10000 e-mails: old version: $ time ./notmuch new No new mail. real 0m0.053s user 0m0.028s sys 0m0.026s new version: $ time ./notmuch new No new mail. real 0m0.032s user 0m0.009s sys 0m0.023s Signed-off-by: Karel Zak <firstname.lastname@example.org> Reviewed-by: Austin Clements <email@example.com> Looks good (faster than, but provably equivalent to the original code! notmuch_directory_get_child_* are side-effect free, db_files/db_subdirs aren't used between where they were set in the old code and where they are set in the new code, and db_files/db_subdirs are initialized to NULL when declared). Another timing data point: Old code: ./notmuch new 0.77s user 0.28s system 99% cpu 1.051 total New code: ./notmuch new 0.09s user 0.27s system 98% cpu 0.368 total
…onfigure This supports the case of a user running "configure --prefix=/foo" then later updating the soruce (including the configure script) and re-running make. In this case, the make invocation will re-run configure. Before this change, this run of configure would lose the user's carefully chosen prefix. This is now fixed so that configrue is re-run with the user's options.
The recent change to support non-source-directory builds broke this case.
Such as: mkdir build cd build ../configure make This is implemented by having the configure script set a srcdir variable in Makefile.config, and then sprinkling $(srcdir) into various make rules. We also use vpath directives to convince GNU make to find the source files from the original source directory.
This would be a handy feature that many people would expect to just work.
In the original json code, search matching nothing would return a valid, empty json array (that is, ""). I broke this in commit 6dcb759 when adding support for --output=threads|messages|tags. This time, while fixing the bug also add a test to the test suite to help avoid future regressions.
Now that we understand the bug here, we rename this test to search-insufficient-from-quoting to clarify the bug being exercised, (which occurs when the From: line contains an unquoted '.' character). We also mark these tests as expected failures until the bug gets fixed.