Jan Janak [Mon, 23 Nov 2009 00:10:56 +0000 (01:10 +0100)]
notmuch.el: Select tag names with completion.
Several commands ask the user for a tag name. With this feature the
user can just press tab and Emacs automatically retrieves the list of
all existing tags from notmuch database with 'notmuch search-tags' and
presents a completion buffer to the user.
This feature is very useful for users who have a large number of tags
because it saves typing and minimizes the risk of typos.
Jan Janak [Mon, 23 Nov 2009 00:10:54 +0000 (01:10 +0100)]
notmuch: New function to retrieve all tags from the database.
This patch adds a new function called notmuch_database_get_all_tags
which can be used to obtain a list of all tags from the database
(in other words, the list contains all tags from all messages). The
function produces an alphabetically sorted list.
To add support for the new function, we rip the guts off of
notmuch_message_get_tags and put them in a new generic function
called _notmuch_convert_tags. The generic function takes a
Xapian::TermIterator as argument and uses the iterator to find tags.
This makes the function usable with different Xapian objects.
Function notmuch_message_get_tags is then reimplemented to call the
generic function with message->doc.termlist_begin() as argument.
Similarly, we implement notmuch_message_database_get_all_tags, the
function calls the generic function with db->xapian_db->allterms_begin()
as argument.
Finally, notmuch_database_get_all_tags is exported through
lib/notmuch.h
modify notmuch_setup_command to return 1 if config file write fails.
This fixes a small bug in notmuch_setup_command such that it returned
OK and output the setup message footer even if the config file write
step failed.
Bart Trojanowski [Wed, 25 Nov 2009 04:34:15 +0000 (23:34 -0500)]
notmuch-show: identify which messages printed matched the query string
The show command outputs all messages in the threads that match the
search-terms. This patch introduces a 'match:[01]' entry to the 'message{'
line output by the show command. Value of 1 indicates that the message is
matching the search expression.
Bart Trojanowski [Wed, 25 Nov 2009 04:28:39 +0000 (23:28 -0500)]
have _notmuch_thread_create mark which messages matched the query
When _notmuch_thread_create() is given a query string, it can return more
messages than just those matching the query. To distinguish those that
matched the query expression, the MATCHING_SEARCH flag is set
appropriately.
Bart Trojanowski [Wed, 25 Nov 2009 04:25:31 +0000 (23:25 -0500)]
message: add flags to notmuch_message_t
This patch allows for different flags, internal to notmuch, to be set on a
message object. The patch does not define any such flags, just the
facilities to manage these flags.
Carl Worth [Wed, 25 Nov 2009 03:08:53 +0000 (19:08 -0800)]
notmuch.el: Quote arguments to protect from shell interpretation.
We want to allow the user to be able to use search expressions with
parentheses and semi-colons, etc. and we definitely don't want the
shell interpreting those!
Previously, our emacs interface was waiting for the "notmuch search"
to complete before it would display anything. Now, we execute the
process asyncrhonously and filter results as they come in.
This takes advantage of the recent work to make "notmuch search"
results stream out steadily. The result is that some search results
will be available nearly instantly and the user can navigate and view
those while additional results continue loading.
Carl Worth [Tue, 24 Nov 2009 05:47:24 +0000 (21:47 -0800)]
lib/messages.c: Make message searches stream as well.
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.
Having actually implemented this, I realized that my
initial approach of providing a function to configure
a button was wrong. Instead I've replaced that with
button types. This then makes it possible to provide
the fully expanded view when all threads in a message
are unread.
It also has the potential to allow global-expansion functions
if that is desireable
This is the same as with citations and signatures.
I used an ellipsis here for the invisible region, which
I think make it more obvious that there are extra headers.
MH-e used this for extra long To/CC headers.
Carl Worth [Tue, 24 Nov 2009 04:18:57 +0000 (20:18 -0800)]
lib/query: Fix notmuch_threads_t to stream results rather than blocking.
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).
Carl Worth [Tue, 24 Nov 2009 04:12:57 +0000 (20:12 -0800)]
notmuch search: Remove the chunked-searching hack.
This was a poor workaround around the fact that the existing
notmuch_threads_t object is implemented poorly. It's got a fine
iterartor-based interface, but the implementation does all of the
work up-front in _create rather than doing the work incrementally
while iterating.
So to start fixing this, first get rid of all the hacks we had working
around this. This drops the --first and --max-threads options from the
search command, (but hopefully nobody was using them
anyway---notmuch.el certainly wasn't).