From: Mark Walters <markwalters1009@gmail.com>
To: notmuch@notmuchmail.org
Subject: Re: [Patch v7 00/13] Add NOTMUCH_MESSAGE_FLAG_EXCLUDED flag
In-Reply-To: <1330641045-27416-1-git-send-email-markwalters1009@gmail.com>
References: <1330641045-27416-1-git-send-email-markwalters1009@gmail.com>
User-Agent: Notmuch/0.11.1+277~gb0f05ff (http://notmuchmail.org) Emacs/23.2.1
	(i486-pc-linux-gnu)
Date: Sat, 03 Mar 2012 03:42:44 +0000
Message-ID: <87y5riuz7v.fsf@qmul.ac.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Precedence: list

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