thread-based email index, search, and tagging https://git.notmuchmail.org/git/notmuch/atom?h=0.7 2011-05-11T20:27:15Z 2011-05-11T20:27:15Z Carl Worth cworth@cworth.org 2011-05-11T20:23:13Z urn:sha1:d5523ead90b6be2b07d4af745b8ed9b980a6b9f1 As of gcc 4.6, there are new warnings from -Wattributes along the lines of: warning: ‘_notmuch_messages’ declared with greater visibility than the type of its field ‘_notmuch_messages::iterator’ [-Wattributes] To squelch these, we decorate all such containing structs with __attribute__((visibility("default"))). We take care to let only the C++ compiler see this, (since the C compiler would otherwise warn about ignored visibility attributes on types). 2011-03-21T06:45:18Z Austin Clements amdragon@mit.edu 2010-12-09T00:26:05Z urn:sha1:f3c1eebfaf8526129ae6946cbcd44a3c602563d6 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. 2011-01-15T23:37:43Z Carl Worth cworth@cworth.org 2011-01-15T22:09:04Z urn:sha1:99cfa2703080c2474e6b8aec0cae86135ae23f1d A new "folder:" prefix in the query string can now be used to match the directories in which mail files are stored. The addition of this feature causes the recently added search-by-folder tests to now pass. 2010-12-08T00:40:05Z Austin Clements amdragon@MIT.EDU 2010-11-17T19:28:26Z urn:sha1:b3caef1f0659dac8183441357c8fee500a940889 This reduces thread search's 1+2t Xapian queries (where t is the number of matched threads) to 1+t queries and constructs exactly one notmuch_message_t for each message instead of 2 to 3. notmuch_query_search_threads eagerly fetches the docids of all messages matching the user query instead of lazily constructing message objects and fetching thread ID's from term lists. _notmuch_thread_create takes a seed docid and the set of all matched docids and uses a single Xapian query to expand this docid to its containing thread, using the matched docid set to determine which messages in the thread match the user query instead of using a second Xapian query. This reduces the amount of time required to load my inbox from 4.523 seconds to 3.025 seconds (1.5X faster). 2010-11-11T22:32:17Z Carl Worth cworth@cworth.org 2010-11-11T22:32:17Z urn:sha1:95dd5fe5d7e9cd8169a6e3174ea27376acd92870 Some people use notmuch with non-maildir files, (for example, email messages in MH format, or else cool things like using sluk[*] to suck down feeds into a format that notmuch can index). To better support uses like that, don't do any renaming for files that are not in a directory named either "new" or "cur". [*] https://github.com/krl/sluk/ 2010-11-11T11:40:19Z Carl Worth cworth@cworth.org 2010-11-11T08:07:24Z urn:sha1:1d02dd64afe245a2b5a8461feeba975e61f0c233 This augments the existing notmuch_message_get_filename by allowing the caller access to all filenames in the case of multiple files for a single message. To support this, we split the iterator (notmuch_filenames_t) away from the list storage (notmuch_filename_list_t) where previously these were a single object (notmuch_filenames_t). Then, whenever the user asks for a file or filename, the message object lazily creates a complete notmuch_filename_list_t and then: For notmuch_message_get_filename, returns the first filename in the list. For notmuch_message_get_filenames, creates and returns a new iterator for the filename list. 2010-11-11T11:40:19Z Carl Worth cworth@cworth.org 2010-11-11T07:26:31Z urn:sha1:d87db8843266caf6b11c1f2f1874328830b23878 The new implementation is simply a talloc-based list of strings. The former support (a list of database terms with a common prefix) is implemented by simply pre-iterating over the terms and populating the list. This should provide no performance disadvantage as callers of thigns like notmuch_directory_get_child_files are very likely to always iterate over all filenames anyway. This new implementation of notmuch_filenames_t is in preparation for adding API to query all of the filenames for a single message. 2010-11-11T11:40:19Z Carl Worth cworth@cworth.org 2010-11-11T01:36:09Z urn:sha1:bb74e9dff80e64734308d5997c756fd96d041235 Instead of having an API for setting a library-wide flag for synchronization (notmuch_database_set_maildir_sync) we instead implement maildir synchronization with two new library functions: notmuch_message_maildir_flags_to_tags and notmuch_message_tags_to_maildir_flags These functions are nicely documented here, (though the implementation does not quite match the documentation yet---as plainly evidenced by the current results of the test suite). 2010-11-10T21:09:31Z Michal Sojka sojkam1@fel.cvut.cz 2010-10-31T21:29:16Z urn:sha1:088801a14ab1ccf4c65e5bf7b50b3a1172c477d7 This patch allows bi-directional synchronization between maildir flags and certain tags. The flag-to-tag mapping is defined by flag2tag array. The synchronization works this way: 1) Whenever notmuch new is executed, the following happens: o New messages are tagged with configured new_tags. o For new or renamed messages with maildir info present in the file name, the tags defined in flag2tag are either added or removed depending on the flags from the file name. 2) Whenever notmuch tag (or notmuch restore) is executed, a new set of flags based on the tags is constructed for every message and a new file name is prepared based on the old file name but with the new flags. If the flags differs and the old message was in 'new' directory then this is replaced with 'cur' in the new file name. If the new and old file names differ, the file is renamed and notmuch database is updated accordingly. The rename happens before the database is updated. In case of crash between rename and database update, the next run of notmuch new brings the database in sync with the mail store again. 2010-11-02T05:35:48Z Carl Worth cworth@cworth.org 2010-11-02T05:01:15Z urn:sha1:c81cecf620d506653a1ead83858b8b3fc240abb5 This prevents any of the private functions from being leaked out through the library interface (at least when compiling with a recent-enough gcc to support the visibility pragma).