On Wed, May 25, 2011 at 6:04 AM, Daniel Schoepe <daniel.schoepe at googlemail.com> wrote: > On Wed, 25 May 2011 00:10:43 -0400, Austin Clements <amdragon at mit.edu> > wrote: >> Out of curiosity, what use cases do you envision for this? ?So far >> I've only heard two, both of which seem like great ideas, but neither >> of which require such a heavy-handed solution: displaying unread >> counts for tags rather than total counts, and hiding unused tags. > > Another thing I use this for, is to hide messages/threads with a > "killed"-tag.
Ah, interesting. > I think a sensible compromise would be to allow either a function or a > string that is appended (which people could set to "and tag:unread") for > the proposed configuration variable and additionally to add a > variable that lists tags that should be hidden (which would also be > easily modifiable in M-x customize). In principle, I completely agree, but the little parser in my head screams "parse error! parse error!" when I feed it "and tag:unread" and that bothers me. May I suggest a slightly different way of looking at this that will quell my inner parser? Instead of configuring a weird "query fragment" like "and tag:unread" to be string-concatenated with the tag query, configure a *filter* query like merely "tag:unread" that narrows down what you'd like to be counted within the scope of a tag. The implementations are hardly different---simply generate the query "tag:<tag> and ( <filter> )"---but a filter is a well-formed query, not some string fragment. Furthermore, the user can't get bitten by precedence and wind up with a query that counts messages that don't even have that tag.