thread-based email index, search, and tagging https://git.notmuchmail.org/git/notmuch/atom?h=0.14 2012-08-12T19:27:45Z 2012-08-12T19:27:45Z Mark Walters markwalters1009@gmail.com 2012-08-07T16:32:18Z urn:sha1:5811550cdd51485ec7ea0f960139eb9ea1741451 The recent change to use json for notmuch-search.el introduced a bug in the code for keeping position on refresh. The problem is a comparison between (plist-get result :thread) and a thread-id returned by notmuch-search-find-thread-id: the latter is prefixed with "thread:" We fix this by adding an option to notmuch-search-find-thread-id to return the bare thread-id. It appears that notmuch-search-refresh-view is the only caller of notmuch-search that supplies a thread-id so this change should be safe (but could theoretically break users .emacs functions). 2012-08-03T00:11:53Z Mark Walters markwalters1009@gmail.com 2012-08-02T07:19:37Z urn:sha1:3fa00020eaac7dfb403cac239a5e59fb2b5d3e2c In commit 5d0883e the function notmuch-search-next-thread was changed. In particular it only goes to the next message if there is a next message. This breaks notmuch-show-archive-thread-then-next. Fix this by going to the "next" message whenever we are on a current message. 2012-07-24T12:23:53Z Austin Clements amdragon@MIT.EDU 2012-07-21T17:37:11Z urn:sha1:5d0883ea1bf5419589ba27c12994c36495f89255 At this point, the only remaining functions that don't support multi-line search result formats are the thread navigation functions. This patch fixes that by rewriting them in terms of notmuch-search-result-{beginning,end}. This changes the behavior of notmuch-search-previous-thread slightly so that if point isn't at the beginning of a result, it first moves point to the beginning of the result. 2012-07-24T12:23:13Z Austin Clements amdragon@MIT.EDU 2012-07-21T17:37:10Z urn:sha1:90e741ef81668d9b7db62b57e9a0c88877e2631e Previously we ignored any notmuch-search-result-format customizations for tag formatting because we needed to be able to parse back in the result line and update the tags in place. We no longer do either of these things, so we can allow customization of this format. (Coincidentally, previously we still allowed too much customization of the tags format, since moving it earlier on the line or removing it from the line would interfere with the tagging mechanism. There is now no problem with doing such things.) 2012-07-24T12:21:48Z Austin Clements amdragon@MIT.EDU 2012-07-21T17:37:09Z urn:sha1:e94b45112ec7262224fdaae03bae75eb47cdece0 Since the result object contains everything that the other text properties recorded, we can remove the other text properties and simply look in the plist of the appropriate result object. 2012-07-24T12:21:38Z Austin Clements amdragon@MIT.EDU 2012-07-21T17:37:08Z urn:sha1:7ba5c86399f8c479442938dd2cc7ad07edd4d985 This simplifies the traversal of regions of results and eliminates the need for save-excursions (which tend to get in the way of maintaining point when we make changes to the buffer). It also fixes some strange corner cases in the old line-based code where results that bordered the region but were not included in it could be affected by region commands. Coincidentally, this also essentially enables multi-line search result formats; the only remaining non-multi-line-capable functions are notmuch-search-{next,previous}-thread, which are only used for interactive navigation. 2012-07-24T12:04:50Z Austin Clements amdragon@MIT.EDU 2012-07-21T17:37:07Z urn:sha1:2a91f636d8c3d478619c0a5040685aca1ac75842 Now that we keep the full thread result object, we can refresh a result after any changes by simply deleting and reconstructing the result line from scratch. A convenient side-effect of this wholesale replacement is that search now re-applies notmuch-search-line-faces when tags change. 2012-07-24T12:04:38Z Austin Clements amdragon@MIT.EDU 2012-07-21T17:37:06Z urn:sha1:60ebc84945731e37d6cbec19ce51c08c408b49e8 Previously, tag-based search result highlighting was done by creating an overlay over each search result. However, overlays have annoying front- and rear-advancement semantics that make it difficult to manipulate text at their boundaries, which the next patch will do. They also have performance problems (creating an overlay is linear in the number of overlays between point and the new overlay, making highlighting a search buffer quadratic in the number of results). Text properties have neither problem. However, text properties make it more difficult to apply multiple faces since, unlike with overlays, a given character can only have a single 'face text property. Hence, we introduce a utility function that combines faces into any existing 'face text properties. Using this utility function, it's straightforward to apply all of the appropriate tag faces in notmuch-search-color-line. 2012-07-24T12:04:27Z Austin Clements amdragon@MIT.EDU 2012-07-21T17:37:05Z urn:sha1:ae30f33093ebca63f8a18fff7054ac147898af94 This also provides utility functions for working with this text property that get its value, find its start, and find its end. 2012-07-12T23:39:36Z Austin Clements amdragon@MIT.EDU 2012-07-09T21:42:41Z urn:sha1:9c5ea07cc66a00132d20db0c8b2094d25ce564ba The JSON format eliminates the complex escaping issues that have plagued the text search format. This uses the incremental JSON parser so that, like the text parser, it can output search results incrementally. This slows down the parser by about ~4X, but puts us in a good position to optimize either by improving the JSON parser (evidence suggests this can reduce the overhead to ~40% over the text format) or by switching to S-expressions (evidence suggests this will more than double performance over the text parser). [1] This also fixes the incremental search parsing test. This has one minor side-effect on search result formatting. Previously, the date field was always padded to a fixed width of 12 characters because of how the text parser's regexp was written. The JSON format doesn't do this. We could pad it out in Emacs before formatting it, but, since all of the other fields are variable width, we instead fix notmuch-search-result-format to take the variable-width field and pad it out. For users who have customized this variable, we'll mention in the NEWS how to fix this slight format change. [1] id:"20110720205007.GB21316@mit.edu"