On Thu, 03 Jun 2010 17:45:20 -0700, Carl Worth <cwo...@cworth.org> wrote: > So I think what we actually want here is an additional member for our > saved-search tuple which indicates the desired search order for that > particular search. That's the only way I see to support a single user > who wants to take advantage of both kinds of searches.
That seems straightforward to implement in the code and only slightly
complicated in the customisation interface (though I haven't done it
yet).
> A separated, but perhaps related idea would be to explicitly support the
> notion of one search being a subset of another. I have an "inbox" search
> (tag:inbox) and several searches that are subsets, ("notmuch" is
> "tag:notmuch and tag:inbox"). If this were setup as an actual hierarchy
> it might have two advantages:
>
> 1. It would be a bit simpler to specify all of theses searches,
> I wouldn't have to keep repeating "and tag:inbox" in each.
> This would be particularly important if I changed the
> criteria for the top-level search.
>
> 2. If the various levels of the hierarchy were displayed
> separately it would be easier for me to focus on processing
> all of my inbox folders (which happen to be
> oldest-first)--archiving each down to 0 messages, without
> being distracted by several (newest-first) saved searches
> that will only ever grow and don't have any
> processing/archiving associated with them.
Writing code to manipulate and use a structure like this would obviously
be some effort, but it doesn't seem overly difficult. More challenging
would be the interface to allow the user to customise the structure to
express their intentions. Do you have any thoughts on that?
dme.
--
David Edmondson, http://dme.org
pgpabviM1QVWk.pgp
Description: PGP signature
_______________________________________________ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
