notmuch/test/maildir-sync, branch 0.17

test: sanitize Date and timestamp fields in json

2013-12-09T13:20:27Z

Eventually we want test messages to have distinct dates to avoid reproducability problems. This sanitization will prevent some test failures when that change is made. Replace the use of a local function in maildir-sync with notmuch_json_show_sanitize

tags_to_maildir_flags: Don't rename if no flags change

2013-09-03T23:41:51Z

notmuch_message_tags_to_maildir_flags() unconditionally moves messages from maildir directory "new/" to maildir directory "cur/", which makes messages lose their "new" status in the MUA. However some users want to keep this "new" status after, for instance, an auto-tagging of new messages. However, as Austin mentioned and according to the maildir specification, messages living in "new/" are not allowed to have flags, even if mutt allows it to happen. For this reason, this patch prevents moving messages from "new/" to "cur/", only if no flags have to be changed. It's hopefully enough to satisfy mutt (and maybe other MUAs showing the "new" status) users checking the "new" status. Changelog: * v2: Fix bool type as well as NULL returned despite having no errors (Austin Clements) * v4: Tag the related test (contributed by Michal Sojka) as working Signed-off-by: Louis Rilling [Condition for keeping messages in new/ was extended to satisfy all tests from the previous patch. -Michal Sojka] [Added by David Bremner, to keep the tests passing at each commit] update insert tests for new maildir synchronization rules As of id:1355952747-27350-4-git-send-email-sojkam1@fel.cvut.cz we are more conservative about moving messages from ./new to ./cur. This updates the insert tests to match

test: Add some missing maildir synchronization tests

2013-09-03T23:36:12Z

As mentioned by Jani Nikula in id:87vcccp4y3.fsf@nikula.org, some cases of maildir synchronization are not covered by our tests. Let's add the missing tests.

test: Adding non-maildir tags does not move message from new to cur

2013-09-03T23:33:17Z

Some MUA's like mutt show the difference between "new" emails living in maildir directory new/, and "old" emails living in maildir directory cur/. However notmuch tag unconditionally moves selected messages from new/ to cur/, even if no maildir synchronized tag is changed. While maildir specification forbids messages with tags living in new/, there is no need to move messages to cur/ when no maildir synchronized tag is changed. Thus notmuch can remain transparent with respect to other MUA's. [ Edited commit log to better describe the intended changes, and tag the test as broken until the actual changes are implemented -- Louis Rilling ] Signed-off-by: Louis Rilling [ Converted to use test_subtest_known_broken, David Bremner ]

notmuch-restore: replace positional argument for input with option

2012-08-06T11:52:45Z

Since notmuch dump doesn't use positional arguments anymore, it seems better to be consistent.

notmuch-dump: remove deprecated positional argument for output file

2012-08-06T11:52:33Z

The syntax --output=filename is a smaller change than deleting the output argument completely, and conceivably useful e.g. when running notmuch under a debugger.

test: Remove unnecessary JSON canonicalization

2012-08-03T23:16:45Z

Format canonicalization of JSON output is no longer necessary, so remove it. Value canonicalization (e.g., normalizing thread IDs) is still necessary, so all of the sanitization functions remain.

test: Uniformly canonicalize actual and expected JSON

2012-08-03T23:14:47Z

Previously, we used a variety of ad-hoc canonicalizations for JSON output in the test suite, but were ultimately very sensitive to JSON irrelevancies such as whitespace. This introduces a new test comparison function, test_expect_equal_json, that first pretty-prints *both* the actual and expected JSON and the compares the result. The current implementation of this simply uses Python's json.tool to perform pretty-printing (with a fallback to the identity function if parsing fails). However, since the interface it introduces is semantically high-level, we could swap in other mechanisms in the future, such as another pretty-printer or something that does not re-order object keys (if we decide that we care about that). In general, this patch does not remove the existing ad-hoc canonicalization because it does no harm. We do have to remove the newline-after-comma rule from notmuch_json_show_sanitize and filter_show_json because it results in invalid JSON that cannot be pretty-printed. Most of this patch simply replaces test_expect_equal and test_expect_equal_file with test_expect_equal_json. It changes the expected JSON in a few places where sanitizers had placed newlines after commas inside strings.

lib: Treat messages in new/ as maildir messages with no flags set

2012-06-10T23:14:56Z

Previously, notmuch new only synchronized maildir flags to tags for files with a maildir "info" part. Since messages in new/ don't have an info part, notmuch would ignore them for flag-to-tag synchronization. This patch makes notmuch consider messages in new/ to be legitimate maildir messages that simply have no maildir flags set. The most visible effect of this is that such messages now automatically get the unread tag.

test: Add broken test for tag synchronization on files delivered to new/

2012-06-10T23:13:19Z

Currently, notmuch new only synchronizes maildir flags to tags for files that have an "info" part. However, in maildir, new mail doesn't gain the info part until it moves from new/ to cur/. Hence, even though mail in new/ doesn't have an info part, it is still a maildir message and thus has maildir flags (though none of them set). The most visible effect of not synchronizing maildir flags for messages in new/ is that newly delivered messages don't get the unread tag (unless it is assigned by some other mechanism, like new.tags). This patch does *not* modify the test for messages in cur/ that do not have an "info" part. Unlike a message in new/, a message in cur/ without an info part is no longer a maildir message, and thus shouldn't be subject to maildir flag synchronization.