thread-based email index, search, and tagging https://git.notmuchmail.org/git/notmuch/atom?h=0.14 2012-07-12T23:39:36Z 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" 2012-07-12T23:39:18Z Austin Clements amdragon@MIT.EDU 2012-07-09T21:42:39Z urn:sha1:f94a50d80af8c2a5513e58db954dd0b1910eb4a8 This advises the search process filter to make it process one character at a time in order to test the pessimal case for incremental search output parsing. The text parser fails this test because it gets tricked into thinking a parenthetical remark in a subject is the tag list. 2012-05-06T22:41:52Z Adam Wolfe Gordon awg+notmuch@xvx.ca 2012-05-06T14:56:15Z urn:sha1:97efed0f0854c2231625057738c1c2db7b37c139 The output of the HTML reply test in the emacs suite can vary depending on which HTML renderers are installed on the machine running the tests. The renderer that is always available is emacs's builtin html2text function. In order to get consistency, force the test to use html2text even if other renderers are available. 2012-05-06T11:48:11Z Adam Wolfe Gordon awg+notmuch@xvx.ca 2012-05-05T19:30:37Z urn:sha1:f6c170fabca8f39e74705e3813504137811bf162 Quote non-text parts nicely by displaying them with mm-display-part before calling message-cite-original to quote them. HTML-only emails can now be quoted correctly. We re-use some code from notmuch-show (notmuch-show-mm-display-part-inline), which has been moved to notmuch-lib.el. Mark the test for this feature as not broken. 2012-05-06T11:47:56Z Adam Wolfe Gordon awg+notmuch@xvx.ca 2012-05-05T19:24:28Z urn:sha1:7fb8ab9f0b470dc236c92686ed33f8e0fa1d5727 With the latest reply infrastructure, we should be able to nicely quote HTML-only emails. But currently emacs quotes the raw HTML instead of parsing it first. This commit adds a test for this case. This test currently marked as broken. 2012-04-12T11:40:33Z Dmitry Kurochkin dmitry.kurochkin@gmail.com 2012-03-10T03:54:15Z urn:sha1:6409a27b2c835223806e4b14cc219c927856c256 This patch removes trailing spaces in notmuch-hello view. A side effect of this change is that tag/query buttons no longer include a space at the end. This means that pressing RET when the point is at the first character after the tag/query button no longer works (note that this is the standard behavior for buttons). We may change this behavior in the future (without adding trailing spaces back) if people would find this change inconvenient. 2012-04-02T20:47:04Z Adam Wolfe Gordon awg+notmuch@xvx.ca 2012-04-01T15:24:23Z urn:sha1:e4844fafec0dd789fe304b412c76f594850b833e In the new reply code, the References header gets inserted by message.el using a function called message-shorten-references. Unlike all the other header-inserting functions, it doesn't put a newline after the header, causing the next header to end up on the same line. In our case, this header happened to be User-Agent, so it's hard to notice. This is probably a bug in message.el, but we need to work around it. This fixes the problem by wrapping message-shorten-references in a function that inserts a newline after if necessary. This should protect against the message.el bug being fixed in the future. 2012-04-02T20:45:36Z Adam Wolfe Gordon awg+notmuch@xvx.ca 2012-04-01T15:24:22Z urn:sha1:bc531924e0463719d7572ed324edb002cfc1c70f By default, emacs hides the User-Agent and References headers when composing mail. This is a good thing for users, but a bad thing for testing, since we can create ugly or invalid headers and not have it show up in the tests. By setting message-hidden-headers to an empty list, we force emacs to show all the headers, so we can check that they're correct. Users won't see this, but it will let us catch future bugs. As a side-effect, this breaks all the reply tests, since there is a bug with the References and User-Agent headers, fixed in the next commit. 2012-04-02T20:45:27Z Adam Wolfe Gordon awg+notmuch@xvx.ca 2012-04-01T15:24:21Z urn:sha1:3737ca6e268e6f45353bfbcc4ac4b1d548c5908d Bug 1: Replying from alternate addresses ---------------------------------------- The reply code was inconsistent in its use of symbols and strings for header names being passed to message.el functions. This caused the From header to be lookup up incorrectly, causing an additional From header to be added with the user's primary address instead of the correct alternate address. This is fixed by using symbols everywhere, i.e. never using strings for header names when interacting with message.el. This change also removes our use of `mail-header`, since we don't use it anywhere else, and using assq makes it clear how the header lists are expected to work. Bug 2: Duplicate headers in emacs 23.2 -------------------------------------- The message.el code in emacs 23.2 assumes that header names will always be passed as symbols, so our use of strings caused problems. The symptom was that on 23.2 (and presumably on earlier versions) the reply message would end up with two of some headers. Converting everything to symbols also fixes this issue. 2012-04-02T20:45:16Z Adam Wolfe Gordon awg+notmuch@xvx.ca 2012-04-01T15:24:20Z urn:sha1:b45b72aa14394ba346a958da7a74303951b41ed4 Since the recent reply changes were pushed, there has been a bug that causes emacs to always reply from the primary address, even if the JSON or default CLI reply output uses an alternate address. This adds two tests to the emacs test library based on the two "Reply form..." tests in the reply test library. One is currently marked broken.