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 A98FB429E28 for ; Wed, 25 May 2011 20:27:15 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: -0.698 X-Spam-Level: X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 tZfiWyiljMiY for ; Wed, 25 May 2011 20:27:15 -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 CEE40431FB6 for ; Wed, 25 May 2011 20:27:14 -0700 (PDT) Received: by qyk7 with SMTP id 7so2851586qyk.5 for ; Wed, 25 May 2011 20:27:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:date:x-google-sender-auth :message-id:subject:from:to:cc:content-type; bh=g483eQto+pCxIko3RKC4NK7aH/kiHptELsoCgy7HQMc=; b=giuEY9ClHAW+TWa2fgN9uvF7yFBAqDqDutG1V0CVF+qM6aWMDBU9UIbKbAXr/osO4S /QivhTVE+Swkj2ejpnMPd536UlPRj1lSTF/xR02fIEKciSs/zjQHonKOatY9x1UWynZ+ /QZDRf1tegIkZv5meVeOjo7d2htaea1uzG1eQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; b=ByprJATPvHPZ3+soIy7Mp6na0yC8LmOc2buRP7+geg8FevdE4tBJuMasTu5J3+K95K 4NzitHMeTlLvs+IeQ/2Ic6GmBwFjdZYS1TQAU9kIZ0uA5TTzLOiR9tA8oPhAIFFcl+O4 fHT36G4pXna5ayragebP8Eee4b9Ny+8a5lG08= MIME-Version: 1.0 Received: by 10.229.78.218 with SMTP id m26mr206463qck.160.1306380434090; Wed, 25 May 2011 20:27:14 -0700 (PDT) Sender: amdragon@gmail.com Received: by 10.229.188.68 with HTTP; Wed, 25 May 2011 20:27:13 -0700 (PDT) Received: by 10.229.188.68 with HTTP; Wed, 25 May 2011 20:27:13 -0700 (PDT) Date: Wed, 25 May 2011 23:27:13 -0400 X-Google-Sender-Auth: jTQ2RQzIKMEHUMjeE0lK0yewspc Message-ID: Subject: Re: [PATCH] emacs: Make the queries used in the all-tags section From: Austin Clements To: Daniel Schoepe Content-Type: multipart/alternative; boundary=00235429d2f4b72c0704a42565f4 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: Thu, 26 May 2011 03:27:15 -0000 --00235429d2f4b72c0704a42565f4 Content-Type: text/plain; charset=ISO-8859-1 On May 25, 2011 7:21 PM, "Daniel Schoepe" wrote: > > On Wed, 25 May 2011 18:42:30 -0400, Austin Clements wrote: > > 'Doh. That's what I get for not reading the surrounding code. I > > misunderstood what your patch was going for and assumed it was what > > *I* wanted notmuch to do, which is to show me useful counts (e.g., > > unread count), but not to change the underlying query. ]:--8) > > I thought about that too, but figured it should be rather rare that > someone wants only a portion of some messages _counted_, but all > displayed when clicking on the search next to the count. My use case of counting only unread messages (but still showing all of them, like just about every other mail client out there) is an example of this. But you're right that I can't think of any other examples (which is why I suggested just baking this specific thing in earlier). > I'm somewhat indifferent, since I rarely use those links > directly, so any more opinions on this are very much appreciated. Actually, here's a new thought that may help address your original problem (assuming I understand it correctly now). One of my design criteria for the custom query parser (need to get back to those patches...) was to support "implicit tag filters" such as hiding everything with tag:spam or tag:killed (or tag:muted, etc) unless these tags are specifically requested by a query. That would apply equally to generated queries like the all tags list, so you could filter out tag:killed messages centrally using a mechanism like this, rather than having to work it in to every query somehow. > > So, to me, it seems like this turns the all tags section into another > > saved searches section, just with a slight twist, and makes me wonder > > if there's a better way to reconcile these. > > Well, it already was sort of a non-configurable saved searches section > before, so I didn't really turn it into one. :) True. > Since the main difference between those sections is the clear visual > distinction, it might be an option to provide the user with functions to > easily declare new sections for the hello screen, where this sort of > thing is configurable. (One possible use that comes to mind would be to > group tags into different categories.) That would be awesome. --00235429d2f4b72c0704a42565f4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On May 25, 2011 7:21 PM, "Daniel Schoepe" <daniel.schoepe@googlemail.com> wrote:<= br> >
> On Wed, 25 May 2011 18:42:30 -0400, Austin Clements <amdragon@mit.edu> wrote:
> > 'Doh. =A0That's what I get for not reading the surroundin= g code. =A0I
> > misunderstood what your patch was going for and assumed it was wh= at
> > *I* wanted notmuch to do, which is to show me useful counts (e.g.= ,
> > unread count), but not to change the underlying query. =A0]:--8)<= br> >
> I thought about that too, but figured it should be rather rare that > someone wants only a portion of some messages _counted_, but all
> displayed when clicking on the search next to the count.

My use case of counting only unread messages (but still showing all of t= hem, like just about every other mail client out there) is an example of th= is. But you're right that I can't think of any other examples (whic= h is why I suggested just baking this specific thing in earlier).

> I'm somewhat indifferent, since I rarely use those links
> directly, so any more opinions on this are very much appreciated.

Actually, here's a new thought that may help address your original p= roblem (assuming I understand it correctly now).=A0 One of my design criter= ia for the custom query parser (need to get back to those patches...) was t= o support "implicit tag filters" such as hiding everything with t= ag:spam or tag:killed (or tag:muted, etc) unless these tags are specificall= y requested by a query.=A0 That would apply equally to generated queries li= ke the all tags list, so you could filter out tag:killed messages centrally= using a mechanism like this, rather than having to work it in to every que= ry somehow.

> > So, to me, it seems like this turns the all tags section into = another
> > saved searches section, just with a slight twist, and makes me wo= nder
> > if there's a better way to reconcile these.
>
> Well, it already was sort of a non-configurable saved searches section=
> before, so I didn't really turn it into one. :)

True.

> Since the main difference between those sections is the clear visua= l
> distinction, it might be an option to provide the user with functions = to
> easily declare new sections for the hello screen, where this sort of > thing is configurable. (One possible use that comes to mind would be t= o
> group tags into different categories.)

That would be awesome.

--00235429d2f4b72c0704a42565f4--