From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/57049 Path: main.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.gnus.general Subject: Re: emulating mozilla's Label command Date: Fri, 16 Apr 2004 10:53:45 -0400 Organization: =?koi8-r?q?=F4=C5=CF=C4=CF=D2=20=FA=CC=C1=D4=C1=CE=CF=D7?= @ Cienfuegos Sender: ding-owner@lists.math.uh.edu Message-ID: <4nk70g9dom.fsf@b2-25-3.bwh.harvard.edu> References: <4noepxs0fo.fsf@b2-25-3.bwh.harvard.edu> <87n05hnny5.fsf@emptyhost.emptydomain.de> <4nad1fq4ja.fsf@b2-25-3.bwh.harvard.edu> <4nk70hav21.fsf@b2-25-3.bwh.harvard.edu> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1082127149 14568 80.91.224.253 (16 Apr 2004 14:52:29 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 16 Apr 2004 14:52:29 +0000 (UTC) Cc: ding@gnus.org Original-X-From: ding-owner+M5589@lists.math.uh.edu Fri Apr 16 16:52:21 2004 Return-path: Original-Received: from malifon.math.uh.edu ([129.7.128.13]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BEUhY-0003as-00 for ; Fri, 16 Apr 2004 16:52:21 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by malifon.math.uh.edu with smtp (Exim 3.20 #1) id 1BEUhM-0003yd-00; Fri, 16 Apr 2004 09:52:08 -0500 Original-Received: from util2.math.uh.edu ([129.7.128.23]) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 1BEUhI-0003yY-00 for ding@lists.math.uh.edu; Fri, 16 Apr 2004 09:52:04 -0500 Original-Received: from justine.libertine.org ([66.139.78.221] ident=postfix) by util2.math.uh.edu with esmtp (Exim 4.30) id 1BEUhH-0007KI-DW for ding@lists.math.uh.edu; Fri, 16 Apr 2004 09:52:03 -0500 Original-Received: from clifford.bwh.harvard.edu (clifford.bwh.harvard.edu [134.174.9.41]) by justine.libertine.org (Postfix) with ESMTP id B776F3A0026 for ; Fri, 16 Apr 2004 09:52:02 -0500 (CDT) Original-Received: from b2-25-3.bwh.harvard.edu (b2-25-3 [134.174.54.60]) by clifford.bwh.harvard.edu (8.10.2+Sun/8.11.0) with ESMTP id i3GEq1115171; Fri, 16 Apr 2004 10:52:02 -0400 (EDT) Original-To: Chris Green X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6;d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" Mail-Followup-To: Chris Green , ding@gnus.org In-Reply-To: (Chris Green's message of "Thu, 15 Apr 2004 16:01:58 -0400") User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (usg-unix-v) Precedence: bulk Xref: main.gmane.org gmane.emacs.gnus.general:57049 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:57049 On Thu, 15 Apr 2004, cmg@dok.org wrote: > Ted Zlatanov 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