Re: emulating mozilla's Label command

[Ted Zlatanov <tzz@lifelogs.com>]

On Thu, 15 Apr 2004, cmg@dok.org wrote:
> Ted Zlatanov <tzz@lifelogs.com> writes:
> 
>> On Tue, 13 Apr 2004, cmg@dok.org wrote:
>>> I glanced at the registry and it seems separating out the parent
>>> threading functions from what directories the registry actually
>>> watches might be desirable.  
>>
>> I don't understand, sorry.
> 
> (defcustom gnus-registry-unfollowed-groups '("delayed" "drafts"
>   "queue") "List of groups that
>   gnus-registry-split-fancy-with-parent won't follow.  The group
>   names are matched, they don't have to be fully qualified."  :group
>   'gnus-registry :type '(repeat string))
> 
> I could see not wanting splitting to follow those directories but
> being able to label an article an article in drafts as a TODO task
> and then pull that task out for as below.

Oh, I see.  That variable only applies to the output of
gnus-registry-split-fancy-with-parent, not to gnus-registry itself.
The gnus-registry tracks articles everywhere.

>>> It looks like the registry cache's enough to make the display of
>>> labels straight from the registry easy.  Would the searching of
>>> the registry for all things having a "label" data be prohibitive?
>>
>> Yes, but why would you?  You just need to look up the article of
>> interest by message ID.
> 
> Wes Hardaker's thread about:
> Wes> What I'd like would be a thread summary something like (badly
> Wes> drawn, sorry):
> Wes> 
> Wes> imap
> Wes>  \- inbox
> Wes>   \- family
> Wes>     - Go to Mom's at 9
> Wes>     - Help sister with her computer
> Wes>   \- work
> Wes>     - Write boss
> Wes>     \- project1
> Wes>      - submit report
> Wes> 
> Wes> But the cool thing would be if each of the topics actually came
> Wes> from a group name (imap.inbox, imap.inbox.family, imap.work,
> Wes> imap.work.project1), ...  And if all the data was auto-gathered
> Wes> from a specified list of folders to work on.
> 
> I'm convinced that the right hooks could create that later by just
> storing the msgids that have labels.

OK, I understand.  The registry will need reverse mappings to do this,
which will use memory and CPU.  So it should be optional, and if it's
off then it will cost the user more CPU to retrieve the reverse
mapping (but the CPU and memory costs will be localized instead of
distributed).  There should be four settings for caching:

t (build cache ASAP and keep it)
nil (never, only build cache when needed and release it afterwards)
'opportunistic (cache is built when needed and reused later)
'(...) (list of types of extra data that should be cached, all others
are built when needed)

This can be a significant concern for people with many thousands of
messages in the registry, so I want to be careful about memory and
CPU use.

What do you think?

Ted