thread-based email index, search, and tagging https://git.notmuchmail.org/git/notmuch/atom?h=0.15_rc1 2012-12-17T13:11:57Z 2012-12-17T13:11:57Z Peter Wang novalazy@gmail.com 2012-12-15T03:06:45Z urn:sha1:732f50a20aac461101986fafec95771c8a686ebe Update tests to expect content-length and content-transfer-encoding fields in show --format=json output, for leaf parts with omitted body content. 2012-12-17T13:08:04Z Peter Wang novalazy@gmail.com 2012-12-15T03:06:42Z urn:sha1:ee425ae2ad8605a1c57ba2f71562db9f060d2cea notmuch_json_show_sanitize replaced "filename" field values even in part structures, where the value is predictable. Make it only normalize the filename value if it is an absolute path (begins with slash), which is true of the Maildir filenames that were intended to be normalized away. 2012-08-03T23:16:45Z Austin Clements amdragon@MIT.EDU 2012-08-03T01:14:48Z urn:sha1:624d1897ce70fde8a41f2ea245db2a5e27f16ce1 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. 2012-08-03T23:14:47Z Austin Clements amdragon@MIT.EDU 2012-08-03T01:14:47Z urn:sha1:a34bb1f9fad7c547eec5c254ce8274f190491186 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. 2012-03-20T00:53:53Z Adam Wolfe Gordon awg+notmuch@xvx.ca 2012-03-18T16:32:36Z urn:sha1:1904b01b96c1b731afb9649e7b5bceffce901b88 This new JSON format for replies includes headers generated for a reply message as well as the headers of the original message. Using this data, a client can intelligently create a reply. For example, the emacs client will be able to create replies with quoted HTML parts by parsing the HTML parts. 2012-03-20T00:50:47Z Adam Wolfe Gordon awg+notmuch@xvx.ca 2012-03-18T16:32:33Z urn:sha1:30172649e8738332edeaf45aa341fe7d20333e8a 2012-03-18T12:14:22Z Austin Clements amdragon@MIT.EDU 2012-03-06T18:48:43Z urn:sha1:b1130bc71c02efb504ad723b56f86618fd186a67 This is fully compatible for root and leaf parts, but now has proper support for interior parts. This requires some design decisions that were guided by what I would want if I were to save a part. Specifically: - Leaf parts are printed without headers and with transfer decoding. This is what makes sense for saving attachments. (Furthermore, the transfer decoding is necessary since, without the headers, the caller would not be able to interpret non-transfer-decoded output.) - Message parts are printed with their message headers, but without enclosing part headers. This is what makes sense for saving a message as a whole (which is a message part) and for saving attached messages. This is symmetric for whole messages and for attached messages, though we special-case the whole message for performance reasons (and corner-case correctness reasons: given malformed input, GMime may not be able to reproduce it from the parsed representation). - Multipart parts are printed with their headers and all child parts. It's not clear what the best thing to do for multipart is, but this was the most natural to implement and can be justified because such parts can't be interpreted without their headers. As an added benefit, we can move the special-case code for part 0 into the raw formatter. 2012-03-18T12:14:21Z Austin Clements amdragon@MIT.EDU 2012-03-06T18:48:38Z urn:sha1:046ab77b1045596ab225296987401fe95eb2fe13 Previously, there was only one CRLF between the terminating boundary of the embedded multipart/alternative and the boundary of the containing multipart. However, according the RFC 1341, 7.2.1: The boundary must be followed immediately either by another CRLF and the header fields for the next part, or by two CRLFs, in which case there are no header fields for the next part and The CRLF preceding the encapsulation line is considered part of the boundary so that it is possible to have a part that does not end with a CRLF (line break). Thus, there must be *two* CRLFs between these boundaries: one that ends the terminating boundary and one that begins the enclosing boundary. While GMime accepted the message we had before, it could not produce such a message. 2012-03-18T12:14:21Z Austin Clements amdragon@MIT.EDU 2012-03-06T18:48:37Z urn:sha1:d2e96a35a5e5eceec158dc255331b6c524810b83 Part 4 is a multipart, not an html part. 2012-03-02T12:35:02Z Mark Walters markwalters1009@gmail.com 2012-03-01T22:30:41Z urn:sha1:c8cf9e92d80f960bb8231b518c6967a7aab7f260 notmuch show outputs the exclude flag so many tests using notmuch show failed. This commit adds "excluded:0" or "excluded: false" to the expected outputs. After this commit there should be no failing tests.