notmuch.el: Use variable notmuch-search-oldest-first to decide the search order
Make sure we use notmuch-search-oldest-first to decide the how
the search result should be displayed. This helps to set the
value to nil and have latest mail shown first
Jan Janak [Wed, 25 Nov 2009 03:30:22 +0000 (04:30 +0100)]
search-tags: Add support for search-terms.
This patch adds support for search-terms to 'notmuch search-tags'. If
no search-term is provided then the command returns a list of all tags
from the database.
If the user provides one or more search-terms as arguments then the
command collects tags from matching messages only.
This could be used by functions in the Emacs mode to further limit the
list of tags offered for completion. For example, functions that remove
tags from message(s) could offer only tags present in the message(s).
Jan Janak [Wed, 25 Nov 2009 03:30:21 +0000 (04:30 +0100)]
lib: New function to collect tags from a list of messages.
This patch adds a new function that can be used to collect a list of
unique tags from a list of messages. 'notmuch search-tags' uses the
function to get a list of tags from messages matching a search-term,
but it has the potential to be used elsewhere so we put it in the lib.
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