Date: Tue, 31 Jan 2012 11:25:06 -0500
From: Austin Clements <amdragon@MIT.EDU>
To: Mark Walters <markwalters1009@gmail.com>
Subject: Re: [PATCH 3/7] lib: Make notmuch_query_search_messages set the
	exclude flag
Message-ID: <20120131162506.GE10898@mit.edu>
References: <8762fu4aqt.fsf@qmul.ac.uk>
	<1327862394-14334-3-git-send-email-markwalters1009@gmail.com>
	<20120131044352.GZ17991@mit.edu> <87y5soccyi.fsf@qmul.ac.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87y5soccyi.fsf@qmul.ac.uk>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: notmuch@notmuchmail.org
Precedence: list

Quoth Mark Walters on Jan 31 at 11:45 am:
> On Mon, 30 Jan 2012 23:43:52 -0500, Austin Clements <amdragon@MIT.EDU> wrote:
> > Quoth Mark Walters on Jan 29 at  6:39 pm:
> > >      notmuch_message_node_t *iterator;
> > >  };
> > >  
> > > diff --git a/lib/notmuch.h b/lib/notmuch.h
> > > index 7929fe7..740d005 100644
> > > --- a/lib/notmuch.h
> > > +++ b/lib/notmuch.h
> > > @@ -449,6 +449,11 @@ typedef enum {
> > >  const char *
> > >  notmuch_query_get_query_string (notmuch_query_t *query);
> > >  
> > > +/* specify whether to results should omit the excluded results rather
> > > + * than just marking them excluded */
> > > +void
> > > +notmuch_query_set_omit_excluded_messages (notmuch_query_t *query, notmuch_bool_t omit);
> > > +
> > 
> > I don't think we should add this API.  The library behavior will not
> > change for library users that don't use excludes and library users
> > that do use excludes should by aware of the excluded flag and do the
> > appropriate thing.
> > 
> > I can see why this is handy in some cases, but I don't think it
> > provides enough utility to warrant becoming part of the permanent and
> > minimal library interface.
> 
> This is really a performance improvement: suppose that there are lots of
> threads that only match in excluded messages. Then without this flag we
> will spend lots of time constructing the thread only for it to be
> ignored. (In contrived situations this could be arbitrarily slower.)

I would prefer to keep the public API minimal and only introduce
something like this if people actually experience performance
problems.