On Thu, 1 Mar 2012 22:30:32 +0000, Mark Walters <markwalters1009@gmail.com> wrote: > This is essentially the same as > id:"1330157204-26094-1-git-send-email-markwalters1009@gmail.com" but > has been rebased against master. The changes are to patch 12/13 for > notmuch-show.el (which was posted as a followup to the previous series) > and to the tests (patch 9/13) which changed in Austin's JSON show > rewrite. There are some problems with this series which were discussed on irc today. In particular the cli notmuch search output is too cluttered for human readability (with lots of excluded threads showing [0/n]) and in some cases it is too slow (it is the same speed as if there were no excludes but looks slower as it outputs less). The following is a proposal to address this. PROPOSAL lib: Change the notmuch_query_set_omit_excluded_messages to a notmuch_query_set_with_excluded_messages option (essentially the negation) This just affects the `seeding' of the thread search: whole threads are returned regardless but unless this is set only threads that match in a non-excluded message are returned. In either case excluded messages have the exclude flag set. cli: replace the --no-excludes option with a --with-excluded option which is roughly the *same*: it outputs the excluded messages (but marks them excluded in so far as the output allows it). I deal with each of count/search and show in turn. count: apply excludes unless --with-excluded. This includes the excluded messages/threads in the count. This could be done with the lib call above but it is easier not to set the excludes in the first place. search: for output=threads|messages|tags we either set or not the exclude terms depending on the --with-excluded option. For output=summary (default) we normally return just those threads which match in a non-excluded message. With the --with-excluded option return all threads that match (using the with_excluded lib call). In both cases the count is [x/y] where x is the number of matching non-excluded messages and y is the total number of messages. It will not be possible to get the pre-exclude output; with the --with-excluded option you get the same threads but the count (x in the above) will show matched and non-excluded instead of matched. show: raw/part are irrelevant as they do not (and should not) apply excludes. When given --with-excluded it returns all messages (in all threads if given --entire-thread) and marks excluded if possible (i.e., unless format=mbox). The remaining cases are all when --with-excluded is not passed. We can have format=json/text/mbox and entire-thread or not. We do not pass with_excluded to the lib so we only get threads matching in a non-excluded message. The question is which of the messages in these threads to output. Note emacs will not care as it will pass in the --with-excluded option. Perhaps --entire-thread should return the whole thread including excluded messages but without --entire-thread just return the matching-non-excluded messages. We have flexibility here as show did not do anything with exclude_tags until this series so not even git users will have got used to any particular behaviour. Does this seem reasonable? The only potential problem I can see is someone wanting exactly the pre-exclude search output. Oh and someone might suggest a better name than --with-excluded: --include-excluded seemed worse! Best wishes Mark