On Wed, May 25, 2011 at 5:21 PM, Daniel Schoepe <daniel.scho...@googlemail.com> wrote: > On Wed, 25 May 2011 15:11:16 -0400, Austin Clements <amdra...@mit.edu> wrote: >> So, perhaps something like >> >> (defcustom notmuch-hello-tag-list-counts nil >> "Method for generating counts displayed in the all tags list. >> >> This variable controls the query used to generate counts for each >> tag in the \"all tags\" list. If nil, the tag list will count >> all messages with each tag. This can be a query string that will >> filter the messages counted for each tag. Finally, this can be a >> function that will be called for each tag and should return a >> filter query for that tag, or nil to hide the tag." >> :type '(choice (const :tag "Count all messages" nil) >> (const :tag "Count unread messages" "tag:unread") >> (const :tag "Custom filter" string) >> (const :tag "Custom filter function" function)) >> :group 'notmuch) > > That is slightly less accurate though, since the query is not only used > to generate the counts, but also the searches that are performed when > one presses return on a tag in the list.
'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) 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. > Ah, thanks. I guess too much exposure to Haskell (and how smart GHC is) > makes me write things in a functional style without thinking about > performance. Hah, been there. I have to constantly remind myself that Elisp is *not* a self-respecting functional programming language, despite how much it may look like Scheme. _______________________________________________ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch