thread-based email index, search, and tagging https://git.notmuchmail.org/git/notmuch/atom?h=debian%2F0.23.7-2 2017-02-22T10:28:03Z 2017-02-22T10:28:03Z David Bremner david@tethera.net 2017-02-22T10:17:47Z urn:sha1:4e649d000b9d3764aea98cb0e1120947d7f76f3d The two g_hash_table functions (insert, add) have different behaviour with respect to existing keys. g_hash_table_insert frees the new key, while g_hash_table_add (which is really g_hash_table_replace in disguise) frees the existing key. With this change 'ref' is live until the end of the function (assuming single-threaded access to 'hash'). We can't guarantee it will continue to be live in the future (i.e. there may be a future key duplication) so we copy it with the allocation context passed to parse_references (in practice this is the notmuch_message_t object whose parents we are finding). Thanks to Tomi for the simpler approach to the problem based on reading the fine glib manual. 2016-10-07T01:45:46Z David Bremner david@tethera.net 2016-10-05T00:35:23Z urn:sha1:af8903df34647d9456e8f3fe26a164959969b451 It seems that no-one tried to compile without Xapian compact support since March of 2015, since that's when I introduced a syntax error in that branch of the ifdef. Given the choice of maintaining this underused branch of code, or bumping the Xapian dependency to a version from 2011, it seems reasonable to do the latter. 2016-09-28T11:14:08Z Tomi Ollila tomi.ollila@iki.fi 2016-09-27T15:06:52Z urn:sha1:1c3a8e0898be614b5183f0ae626386f7746e7e07 Found by gcc 6.1.1 -Wmisleading-indentation option (set by -Wall). 2016-09-21T21:14:25Z Daniel Kahn Gillmor dkg@fifthhorseman.net 2016-07-08T09:15:36Z urn:sha1:693ca8d8a80438ce1e361e7e6d22288f52a11c55 We want to be able to query the properties directly, like: notmuch count property:foo=bar which should return a count of messages where the property with key "foo" has value equal to "bar". 2016-09-21T21:14:24Z David Bremner david@tethera.net 2016-06-13T01:05:48Z urn:sha1:4dfb69169e6b685670ebdeedab898c31adc995b2 This is a first step towards providing an API to attach arbitrary (key,value) pairs to messages and retrieve all of the values for a given key. 2016-08-18T08:11:37Z David Bremner david@tethera.net 2016-08-18T08:06:54Z urn:sha1:9e177b236c7054bc6a51c4718bfd4b31cd4f8b20 I believe the current one is misleading, because in my experiments Xapian did not add : when prefix and term were both upper case. Indeed, it's hard to see how it could, because prefixes are added at a layer above Xapian in our code. See _notmuch_message_add_term for an example. Also try to explain why this is a good idea. As far as I can ascertain, this is more of an issue for a system trying to work with an unknown set of prefixes. Since notmuch has a fixed set of prefixes, and we can hopefully be trusted not to add XGOLD and XGOLDEN as prefixes, it is harder for problems to arise. 2016-08-09T00:34:11Z David Bremner david@tethera.net 2016-07-15T10:25:41Z urn:sha1:293186d6c6b1c4d158413de5412e6b4345e94970 _notmuch_database_log clears the log buffer each time. Rather than introducing more complicated semantics about for this function, provide a second function that does not clear the buffer. This is mainly a convenience function for callers constructing complex or multi-line log messages. The changes to query.cc are to make sure that the common code path of the new function is tested. 2016-06-29T07:03:34Z Istvan Marko notmuch@kismala.com 2016-06-26T15:29:43Z urn:sha1:9b60dc3cd9224eddfe9bc5cf74eeaa5f0d599d04 Xapian 1.3 has introduced the DB_RETRY_LOCK flag (Xapian bug 275). Detect it in configure and optionally use it. With this flag commands that need the write lock will wait for their turn instead of aborting when it's not immediately available. Amended by db: allow disabling in configure 2016-06-10T12:20:22Z David Bremner david@tethera.net 2016-06-10T02:35:27Z urn:sha1:4291f326809692bad61b50f942dc366e59ab30ef The field processor objects need to be deallocated explicitly just like the range processors (or a talloc destructor defined). 2016-06-07T10:51:57Z David Bremner david@tethera.net 2016-06-04T22:17:41Z urn:sha1:ba0b95f846820b1d71f67731a8c38ac2866c921a This probably should have been part of 3458e3c89c, but I missed it.