thread-based email index, search, and tagging https://git.notmuchmail.org/git/notmuch/atom?h=0.13.2 2012-03-20T00:53:53Z 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. 2012-03-01T12:28:13Z Austin Clements amdragon@MIT.EDU 2012-02-20T00:26:26Z urn:sha1:86f89385c3bc34cd91002cc057f6a615b6ab76a9 This has three ramifications: - Blank To and Cc headers are no longer output for messages. - Dates are now canonicalized for messages, which means they always have a day of the week and GMT is printed +0000 (never -0000) - Invalid From message headers are handled slightly differently, since they get parsed by GMime now instead of notmuch. 2012-03-01T12:28:02Z Austin Clements amdragon@MIT.EDU 2012-02-20T00:26:25Z urn:sha1:2209d7b9520000fbd6941b1e0e8521da90f443c6 Previously, top-level message headers were printed as Subject, From, To, Date, while embedded message headers were printed From, To, Subject, Date. This makes both cases use the former order and updates the tests accordingly. 2012-01-23T11:41:46Z Austin Clements amdragon@MIT.EDU 2012-01-23T02:31:12Z urn:sha1:0bd09f844677ba361318d129bd01e21b0f7c1bd9 Previously, top-level message headers were printed as Subject, From, To, Date, while embedded message headers were printed From, To, Subject, Date. This makes both cases use the former order and updates the tests accordingly. Strangely, the raw format also uses this function, so this also fixes the two raw format tests affected by this change. 2011-10-06T13:13:20Z Jameson Graef Rollins jrollins@finestructure.net 2011-06-08T19:30:08Z urn:sha1:5d21d5ea0c6d2113aab9eb7f29463b09e7eacca5 In reply, the quoted text does not need to mention that the original message had "application/pgp-signed" or "application/pgp-encrypted" parts.