notmuch/lib/query.cc, branch 0.3.1

lib: Ensure notmuch_query_search_messages returns NULL on an exception.

2010-04-24T14:27:50Z

Previously, this function may have segfaulted immediately after reporting the exception.

query.cc: allow to return query results unsorted

2010-04-21T23:06:05Z

Previously, we always sorted the returned results by some string value, (newest-to-oldest by default), however in some cases (as when applying tags to a search result) we are not interested in any special order. This introduces a NOTMUCH_SORT_UNSORTED value that does just that. It is not used at the moment anywhere in the code. Signed-off-by: Sebastian Spaeth

Name thread based on matching msgs instead of first msg.

2010-04-21T21:56:53Z

At the moment all threads are named based on the name of the first message in the thread. However, this can cause problems if people either start new threads by replying-all (as unfortunately, many out there do) or change the subject of their mails to reflect a shift in a thread on a list. This patch names threads based on (a) matches for the query, and (b) the search order. If the search order is oldest-first (as in the default inbox) it chooses the oldest matching message as the subject. If the search order is newest-first it chooses the newest one. Reply prefixes ("Re: ", "Aw: ", "Sv: ", "Vs: ") are ignored (case-insensitively) so a Re: won't change the subject. Note that this adds a "sort" argument to _notmuch_thread_create and _thread_add_matched_message, so that when constructing the thread we can be aware of the sort order. Signed-off-by: Jesse Rosenthal

lib: Handle "*" as a query string to match all messages.

2010-04-10T00:43:58Z

This seems like a generally useful thing to support, (but the previous support through an empty string was not convenient for some users, (such as the command-line client).

lib: Rename iterator functions to prepare for reverse iteration.

2010-03-09T17:22:29Z

We rename 'has_more' to 'valid' so that it can function whether iterating in a forward or reverse direction. We also rename 'advance' to 'move_to_next' to setup parallel naming with the proposed functions 'move_to_first', 'move_to_last', and 'move_to_previous'.

lib: Explicitly set BoolWeight when searching.

2010-01-09T19:16:40Z

All notmuch searches currently sort by value (either date or message ID) so it's just wasted effort for Xapian to compute relevance values for each result. We now explicitly tell Xapian that we're uninterested in the relevance values.

Silence compiler warning by initializing a variable.

2009-11-28T02:38:06Z

If Xapian threw an exception on notmuch_query_count_messages the count variable could be used uninitialized. Initialize count to solve the problem. Signed-off-by: Jeffrey C. Ollie

lib/messages.c: Make message searches stream as well.

2009-11-24T19:33:09Z

Xapian provides an interator-based interface to all search results. So it was natural to make notmuch_messages_t be iterator-based as well. Which we did originally. But we ran into a problem when we added two APIs, (_get_replies and _get_toplevel_messages), that want to return a messages iterator that's *not* based on a Xapian search result. My original compromise was to use notmuch_message_list_t as the basis for all returned messages iterators in the public interface. This had the problem of introducing extra latency at the beginning of a search for messages, (the call would block while iterating over all results from Xapian, converting to a message list). In this commit, we remove that initial conversion and instead provide two alternate implementations of notmuch_messages_t (one on top of a Xapian iterator and one on top of a message list). With this change, I tested a "notmuch search" returning *many* results as previously taking about 7 seconds before results started appearing, and now taking only 2 seconds.

lib/query: Drop the first and max_messages arguments from search_messages.

2009-11-24T04:25:13Z

These only existed to support the chunky-searching hack, but that was recently dropped anyway.

lib/query: Fix notmuch_threads_t to stream results rather than blocking.

2009-11-24T04:18:57Z

Previously, notmuch_query_search_threads would do all the work, so the caller would block until all results were processed. Now, we do the work as we go, as the caller iterates with notmuch_threads_next. This means that once results start coming back from "notmuch search" they just keep continually streaming. There's still some initial blocking before the first results appear because the notmuch_messages_t object has the same bug (for now).