thread-based email index, search, and tagging https://git.notmuchmail.org/git/notmuch/atom?h=0.17 2013-01-07T02:40:32Z 2013-01-07T02:40:32Z Austin Clements amdragon@MIT.EDU 2013-01-06T20:22:41Z urn:sha1:425e2bc81263230df301c67d93c64ff9685ff840 This switches the new batch-tag format away from using a home-grown hex-encoding scheme for message IDs in the dump to simply using Xapian queries with Xapian quoting syntax. This has a variety of advantages beyond presenting a cleaner and more consistent interface. Foremost is that it will dramatically simplify the quoting for batch tagging, which shares the same input format. While the hex-encoding is no better or worse for the simple ID queries used by dump/restore, it becomes onerous for general-purpose queries used in batch tagging. It also better handles strange cases like "id:foo and bar", since this is no longer syntactically valid. 2013-01-06T14:04:19Z David Bremner bremner@debian.org 2012-12-26T19:36:33Z urn:sha1:d705a6a45bf691b60101203bd09a459be255dceb This patch corrects several undesirable behaviours: 1) Empty files were not detected, leading to buffer read overrun. 2) An initial blank line cause restore to silently abort 3) Initial comment line caused format detection to fail 2013-01-06T13:35:41Z David Bremner bremner@debian.org 2012-12-26T19:36:32Z urn:sha1:4dea9bb442f18081347708bc5446db505441fbba Three of these are marked broken; the third is a regression test, since it passes by virtue of batch-tag being the default input format. 2012-12-09T17:33:34Z David Bremner bremner@debian.org 2012-12-08T12:34:00Z urn:sha1:0f066ece0f6aa7c02116f8ba3f06b5a005091678 We want to test both that error/warning messages are generated when they should be, and not generated when they should not be. This varies between restore and batch tagging. 2012-12-09T17:33:34Z David Bremner bremner@debian.org 2012-11-24T21:20:15Z urn:sha1:f9878f917352d8f49c44496b6a0a4ce38ef901d4 These one need the completed functionality in notmuch-restore. Fairly exotic tags are tested, but no weird message id's. We test each possible input to autodetection, both explicit (with --format=auto) and implicit (without --format). 2012-12-09T17:33:34Z David Bremner bremner@debian.org 2011-12-13T03:22:53Z urn:sha1:452f8748c45d38b96706cc04e7b2dc98fc72ec78 Now we can actually round trip these crazy tags and and message ids. hex-xcode is no longer needed as it's built in. 2012-12-08T14:40:55Z David Bremner bremner@debian.org 2012-12-05T02:48:37Z urn:sha1:10085656d5db8e9d26f83ad0b62f9428bb5425c0 It's important this does not rely on restore, since it hasn't been written yet. 2012-12-02T23:09:01Z David Bremner bremner@debian.org 2012-08-05T18:13:13Z urn:sha1:953c3fa853749bd647611c1258b282fb09fb1fdf We demonstrate the current notmuch restore parser being confused by message-id's and tags containing non alpha numeric characters (particularly space and parentheses are problematic because they are not escaped by notmuch dump). We save the files as hex escaped on disk so that terminal emulators will not get confused if the test fails (as we mostly expect it to do). 2012-11-17T14:24:24Z David Bremner bremner@debian.org 2012-11-16T12:31:19Z urn:sha1:be66f3f70937454b367b01bdee0238e38fbf12fa It seems we have never tested the case that restore --accumulate actually adds tags. I noticed this when I started optimizing and no tests failed. The bracketing with "restore --input=dump.expected" are to make sure we start in a known state, and we leave the database in a known state for the next test. 2012-11-17T14:18:00Z David Bremner bremner@debian.org 2012-11-17T14:18:00Z urn:sha1:7d1a2ca0ce0b20a5436225824c0982dfa0c29b45 Thanks to Ethan for the suggestion.