On Wed, May 25, 2011 at 5:21 PM, Daniel Schoepe
<daniel.schoepe at googlemail.com> wrote:
> On Wed, 25 May 2011 15:11:16 -0400, Austin Clements <amdragon at 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.

Reply via email to