From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id AB444431FD0 for ; Wed, 25 May 2011 07:44:52 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: -0.699 X-Spam-Level: X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled Received: from olra.theworths.org ([127.0.0.1]) by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HpowIKPFK6nV for ; Wed, 25 May 2011 07:44:52 -0700 (PDT) Received: from mail-qy0-f174.google.com (mail-qy0-f174.google.com [209.85.216.174]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by olra.theworths.org (Postfix) with ESMTPS id 136CE431FB6 for ; Wed, 25 May 2011 07:44:52 -0700 (PDT) Received: by qyk7 with SMTP id 7so2463252qyk.5 for ; Wed, 25 May 2011 07:44:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=5/TcBN5q7tBtD53ySpEDf8g+G8TPWILY7DSoGrXZYAI=; b=i+tRZ70U82juMQ6KL1kmJufmAXLq1fPQ9nL3E7KvTG/ROlu4A8QP/H/boTjWGu+2SP BQtW9qdUEfOo+9IzfOhUS+6llLUXSzBfhHYDO/xw7qHl6O3cRSHFpOUh0bly9mL/GqYO GUQ74QcK6hT/IbGtwfSE1PVjDNgzEMy7O918M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=UYZW+S7ftVaens/23AXhteJ/cNvI14OwV0R4aCqXqRsM0ydcWS4XiYp5KAl9R0W9+N CjA186+2OKtE/9J9ixeXA1A2kOR4r7vtt3+B99Wjrto7dCUTiiF/y0evn8vvB8wQRtG9 /kMKsPObjj1swIypXkmBltEsEKZSdlhJQc+Mc= MIME-Version: 1.0 Received: by 10.229.35.1 with SMTP id n1mr3858840qcd.84.1306334691178; Wed, 25 May 2011 07:44:51 -0700 (PDT) Sender: amdragon@gmail.com Received: by 10.229.188.68 with HTTP; Wed, 25 May 2011 07:44:51 -0700 (PDT) In-Reply-To: <871uznqeox.fsf@tredergarh.home.box> References: <87fwoath2s.fsf@gilead.home.box> <871uznqeox.fsf@tredergarh.home.box> Date: Wed, 25 May 2011 10:44:51 -0400 X-Google-Sender-Auth: EfzZJtuuv2FJr-NyLDKKVKCv2jM Message-ID: Subject: Re: [PATCH] emacs: Make the queries used in the all-tags section From: Austin Clements To: Daniel Schoepe Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: notmuch@notmuchmail.org X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 14:44:52 -0000 On Wed, May 25, 2011 at 6:04 AM, Daniel Schoepe wrote: > On Wed, 25 May 2011 00:10:43 -0400, Austin Clements wr= ote: >> Out of curiosity, what use cases do you envision for this? =A0So 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: and ( )"---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.