Re: [PATCH] emacs: wash: make word-wrap bound message width
[notmuch-archives.git] / 2c / 1452fa53c632b8a4299fb21c8bc7f15eabf36e
1 Return-Path: <m.walters@qmul.ac.uk>\r
2 X-Original-To: notmuch@notmuchmail.org\r
3 Delivered-To: notmuch@notmuchmail.org\r
4 Received: from localhost (localhost [127.0.0.1])\r
5         by olra.theworths.org (Postfix) with ESMTP id C027C431FAF\r
6         for <notmuch@notmuchmail.org>; Fri,  2 Mar 2012 19:41:01 -0800 (PST)\r
7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
8 X-Spam-Flag: NO\r
9 X-Spam-Score: 1.401\r
10 X-Spam-Level: *\r
11 X-Spam-Status: No, score=1.401 tagged_above=-999 required=5\r
12         tests=[DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001,\r
13         FREEMAIL_REPLY=2.499, NML_ADSP_CUSTOM_MED=1.2, RCVD_IN_DNSWL_MED=-2.3]\r
14         autolearn=disabled\r
15 Received: from olra.theworths.org ([127.0.0.1])\r
16         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
17         with ESMTP id 0t-YTJQLf8-G for <notmuch@notmuchmail.org>;\r
18         Fri,  2 Mar 2012 19:40:59 -0800 (PST)\r
19 Received: from mail2.qmul.ac.uk (mail2.qmul.ac.uk [138.37.6.6])\r
20         (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))\r
21         (No client certificate requested)\r
22         by olra.theworths.org (Postfix) with ESMTPS id A90CD431FAE\r
23         for <notmuch@notmuchmail.org>; Fri,  2 Mar 2012 19:40:59 -0800 (PST)\r
24 Received: from smtp.qmul.ac.uk ([138.37.6.40])\r
25         by mail2.qmul.ac.uk with esmtp (Exim 4.71)\r
26         (envelope-from <m.walters@qmul.ac.uk>)\r
27         id 1S3fq3-0003qx-RI; Sat, 03 Mar 2012 03:40:56 +0000\r
28 Received: from 94-192-233-223.zone6.bethere.co.uk ([94.192.233.223]\r
29         helo=localhost)\r
30         by smtp.qmul.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69)\r
31         (envelope-from <m.walters@qmul.ac.uk>)\r
32         id 1S3fq3-0004gc-GU; Sat, 03 Mar 2012 03:40:55 +0000\r
33 From: Mark Walters <markwalters1009@gmail.com>\r
34 To: notmuch@notmuchmail.org\r
35 Subject: Re: [Patch v7 00/13] Add NOTMUCH_MESSAGE_FLAG_EXCLUDED flag\r
36 In-Reply-To: <1330641045-27416-1-git-send-email-markwalters1009@gmail.com>\r
37 References: <1330641045-27416-1-git-send-email-markwalters1009@gmail.com>\r
38 User-Agent: Notmuch/0.11.1+277~gb0f05ff (http://notmuchmail.org) Emacs/23.2.1\r
39         (i486-pc-linux-gnu)\r
40 Date: Sat, 03 Mar 2012 03:42:44 +0000\r
41 Message-ID: <87y5riuz7v.fsf@qmul.ac.uk>\r
42 MIME-Version: 1.0\r
43 Content-Type: text/plain; charset=us-ascii\r
44 X-Sender-Host-Address: 94.192.233.223\r
45 X-QM-SPAM-Info: Sender has good ham record.  :)\r
46 X-QM-Body-MD5: 7417e2e565252e3ecd8112db2c0496fd (of first 20000 bytes)\r
47 X-SpamAssassin-Score: -1.2\r
48 X-SpamAssassin-SpamBar: -\r
49 X-SpamAssassin-Report: The QM spam filters have analysed this message to\r
50         determine if it is\r
51         spam. We require at least 5.0 points to mark a message as spam.\r
52         This message scored -1.2 points.\r
53         Summary of the scoring: \r
54         * -2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/,\r
55         *      medium trust\r
56         *      [138.37.6.40 listed in list.dnswl.org]\r
57         * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail\r
58         provider *      (markwalters1009[at]gmail.com)\r
59         * -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay\r
60         *      domain\r
61         *  1.0 FREEMAIL_REPLY From and body contain different freemails\r
62         *  0.1 AWL AWL: From: address is in the auto white-list\r
63 X-QM-Scan-Virus: ClamAV says the message is clean\r
64 X-BeenThere: notmuch@notmuchmail.org\r
65 X-Mailman-Version: 2.1.13\r
66 Precedence: list\r
67 List-Id: "Use and development of the notmuch mail system."\r
68         <notmuch.notmuchmail.org>\r
69 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
70         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
71 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
72 List-Post: <mailto:notmuch@notmuchmail.org>\r
73 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
74 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
75         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
76 X-List-Received-Date: Sat, 03 Mar 2012 03:41:01 -0000\r
77 \r
78 On Thu,  1 Mar 2012 22:30:32 +0000, Mark Walters <markwalters1009@gmail.com> wrote:\r
79 > This is essentially the same as\r
80 > id:"1330157204-26094-1-git-send-email-markwalters1009@gmail.com" but\r
81 > has been rebased against master. The changes are to patch 12/13 for\r
82 > notmuch-show.el (which was posted as a followup to the previous series)\r
83 > and to the tests (patch 9/13) which changed in Austin's JSON show\r
84 > rewrite.\r
85 \r
86 There are some problems with this series which were discussed on irc\r
87 today. In particular the cli notmuch search output is too cluttered for\r
88 human readability (with lots of excluded threads showing [0/n]) and in\r
89 some cases it is too slow (it is the same speed as if there were no\r
90 excludes but looks slower as it outputs less). The following is a\r
91 proposal to address this.\r
92 \r
93 PROPOSAL\r
94 \r
95 lib: Change the notmuch_query_set_omit_excluded_messages to a\r
96 notmuch_query_set_with_excluded_messages option (essentially the\r
97 negation) This just affects the `seeding' of the thread search: whole\r
98 threads are returned regardless but unless this is set only threads that\r
99 match in a non-excluded message are returned. In either case excluded\r
100 messages have the exclude flag set.\r
101 \r
102 cli: replace the --no-excludes option with a --with-excluded option\r
103 which is roughly the *same*: it outputs the excluded messages (but marks\r
104 them excluded in so far as the output allows it). I deal with each of\r
105 count/search and show in turn.\r
106 \r
107 count: apply excludes unless --with-excluded. This includes the excluded\r
108 messages/threads in the count. This could be done with the lib call\r
109 above but it is easier not to set the excludes in the first place.\r
110 \r
111 search: for output=threads|messages|tags we either set or not the\r
112 exclude terms depending on the --with-excluded option. \r
113 \r
114 For output=summary (default) we normally return just those threads which\r
115 match in a non-excluded message. With the --with-excluded option return\r
116 all threads that match (using the with_excluded lib call). In both cases\r
117 the count is [x/y] where x is the number of matching non-excluded\r
118 messages and y is the total number of messages.  It will not be possible\r
119 to get the pre-exclude output; with the --with-excluded option you get\r
120 the same threads but the count (x in the above) will show matched and\r
121 non-excluded instead of matched.\r
122 \r
123 show: raw/part are irrelevant as they do not (and should not) apply\r
124 excludes. \r
125 \r
126 When given --with-excluded it returns all messages (in all threads if\r
127 given --entire-thread) and marks excluded if possible (i.e., unless\r
128 format=mbox).\r
129 \r
130 The remaining cases are all when --with-excluded is not passed. We can\r
131 have format=json/text/mbox and entire-thread or not. We do not pass\r
132 with_excluded to the lib so we only get threads matching in a\r
133 non-excluded message. The question is which of the messages in these\r
134 threads to output. Note emacs will not care as it will pass in the\r
135 --with-excluded option.\r
136 \r
137 Perhaps --entire-thread should return the whole thread including\r
138 excluded messages but without --entire-thread just return the\r
139 matching-non-excluded messages. We have flexibility here as show did not\r
140 do anything with exclude_tags until this series so not even git users\r
141 will have got used to any particular behaviour.\r
142 \r
143 Does this seem reasonable? The only potential problem I can see is\r
144 someone wanting exactly the pre-exclude search output. Oh and someone\r
145 might suggest a better name than --with-excluded: --include-excluded\r
146 seemed worse!\r
147 \r
148 Best wishes\r
149 \r
150 Mark\r