aboutsummaryrefslogtreecommitdiffhomepage
path: root/lib/notmuch-private.h
Commit message (Collapse)AuthorAge
...
* Makefile: Incorporate getline implementation into the build.Gravatar Carl Worth2009-12-01
| | | | | It's unconditional for a very short time. We expect to soon be building it only if necessary.
* lib/messages.c: Make message searches stream as well.Gravatar Carl Worth2009-11-24
| | | | | | | | | | | | | | | | | | | | | | | | 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.
* Permit opening the notmuch database in read-only mode.Gravatar Chris Wilson2009-11-21
| | | | | | | | | We only rarely need to actually open the database for writing, but we always create a Xapian::WritableDatabase. This has the effect of preventing searches and like whilst updating the index. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Carl Worth <cworth@cworth.org>
* TypsosGravatar Ingmar Vanhassel2009-11-18
|
* database: Make _parse_message_id static once again.Gravatar Carl Worth2009-11-17
| | | | | | | We had exposed this to the internal implementation for a short time, (only while we had the silly code fetching In-Reply-To values from message files instead of from the database). Make this private again as it should be.
* Fix "too many open files" bug by closing message files when done with them.Gravatar Keith Packard2009-11-17
| | | | | | | | | | | | | | | | | | | | | The message file header parsing code parses only enough of the file to find the desired header fields, then it leaves the file open until the next header parsing call or when the message is no longer in use. If a large number of messages end up being active, this will quickly run out of file descriptors. Here, we add support to explicitly close the message file within a message, (_notmuch_message_close) and call that from thread construction code. Signed-off-by: Keith Packard <keithp@keithp.com> Edited-by: Carl Worth <cworth@cworth.org>: Many portions of Keith's original patch have since been solved other ways, (such as the code that changed the handling of the In-Reply-To header). So the final version is clean enough that I think even Keith would be happy to have his name on it.
* Remove the talloc_owner argument from create_for_message_id.Gravatar Carl Worth2009-11-17
| | | | | | | This function has only one caller, and that one caller was passing the same value for both talloc_owner and the notmuch database. Dropping the redundant argument simplifies the documentation of this function considerably.
* notmuch show: Implement proper thread ordering/nesting of messages.Gravatar Carl Worth2009-11-15
| | | | | | | | We now properly analyze the in-reply-to headers to create a proper tree representing the actual thread and present the messages in this correct thread order. Also, there's a new "depth:" value added to the "message{" header so that clients can format the thread as desired, (such as by indenting replies).
* Add _notmuch_message_get_in_reply_to.Gravatar Carl Worth2009-11-15
| | | | | | | The existing notmuch_message_get_header is *almost* good enough for this, except that we also need to remove the '<' and '>' delimiters. We'll probably want to implement this function with database storage in the future rather than loading the email message.
* Remove obsolete notmuch_message_get_subject prototype.Gravatar Carl Worth2009-11-15
| | | | | | This prototype has been sitting around for a while with no function implementing it. I wonder if there's a compiler warning I could turn on to catch these things.
* lib/messages: Add new notmuch_message_list_t to internal interface.Gravatar Carl Worth2009-11-15
| | | | | | | | | | | | Previously, the notmuch_messages_t object was a linked list built on top of a linked-list node with the odd name of notmuch_message_list_t. Now, we've got much more sane naming with notmuch_message_list_t being a list built on a linked-list node named notmuch_message_node_t. And now the public notmuch_messages_t object is a separate iterator based on notmuch_message_node_t. This means the interfaces for the new notmuch_message_list_t object are now made available to the library internals.
* Export _parse_message_id to the library implementation.Gravatar Carl Worth2009-11-15
| | | | | | Not exported through the public interface, but the thread code is going to want to be able to parse In-Reply-To headers so needs access to this code.
* lib: Move notmuch_messages_t code from query.cc to new messages.cGravatar Carl Worth2009-11-14
| | | | | | | | | | | | | The new object is simply a linked-list of notmuch_message_t objects, (unlike the old object which contained a couple of Xapian iterators). This works now by the query code immediately iterator over all results and creating notmuch_message_t objects for them, (rather than waiting to create the objects until the notmuch_messages_get call as we did earlier). The point of this change is to allow other instances of lists of messages, (such as in notmuch_thread_t), that are not directly related to Xapian search results.
* notmuch search: Print the number of matched/total messages for each thread.Gravatar Carl Worth2009-11-12
| | | | | | | | | | | | | | | | | | | Note that we don't print the number of *unread* messages, but instead the number of messages that matched the search terms. This is in keeping with our philosophy that the inbox is nothing more than a search view. If we search for messages with an inbox tag, then that's what we'll get a count of. (And if somebody does want to see unread counts, then they can search for the "unread" tag.) Getting the number of matched messages is really nice when doing historical searches. For example in a search like: notmuch search tag:sent (where the "sent" tag has been applied to all messages originating from the user's email address)---here it's really nice to be able to see a thread where the user just mentioned one point [1/13] vs. really getting involved in the discussion [10/29].
* notmuch search: Print all authors contributing to a thread.Gravatar Carl Worth2009-11-12
| | | | | | | | We've now expanded the notmuch_thread_create function to fire off a secondary database query to find all the messages that belong to this particular thread. This allows us to now have the complete authors' list for the thread, and will also make it trivial to print accurate message counts for threads in the future.
* libify: Move library sources down into lib directory.Gravatar Carl Worth2009-11-09
A "make" invocation still works from the top-level, but not from down inside the lib directory yet.