From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/9237 Path: main.gmane.org!not-for-mail From: Sudish Joseph Newsgroups: gmane.emacs.gnus.general Subject: Re: NoCeM flakiness in 0.74 and higher Date: 17 Dec 1996 15:53:13 -0500 Sender: sj@atreides.mindspring.com Message-ID: References: NNTP-Posting-Host: coloc-standby.netfonds.no X-Trace: main.gmane.org 1035149291 17249 80.91.224.250 (20 Oct 2002 21:28:11 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 21:28:11 +0000 (UTC) Return-Path: Original-Received: from ifi.uio.no (0@ifi.uio.no [129.240.64.2]) by deanna.miranova.com (8.8.4/8.8.4) with SMTP id NAA29076 for ; Tue, 17 Dec 1996 13:14:34 -0800 Original-Received: from atreides.mindspring.com (qmailr@atreides.mindspring.com [204.180.142.236]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Tue, 17 Dec 1996 21:53:12 +0100 Original-Received: (qmail 10951 invoked by uid 52477); 17 Dec 1996 20:53:14 -0000 Original-To: The Ding List In-Reply-To: Lars Magne Ingebrigtsen's message of 17 Dec 1996 20:16:36 +0100 Original-Lines: 47 X-Mailer: Red Gnus v0.76/XEmacs 20.0 Xref: main.gmane.org gmane.emacs.gnus.general:9237 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:9237 Lars Magne Ingebrigtsen writes: > Can't you just remove a.n.m from `gnus-nocem-groups'? I did. But from what I posted, isn't it indicative of a (pretty scary) bug? Namely that gnus has lost track of what articles it has already seen. >> In particular, it'd be neat if one could have an alist that let you >> specify the type of score entry you want generated for articles >> that're being eliminated by nocem. A followup entry (I.e., low score >> on references) would be the most useful. > Yes, that would be useful. It might be tricky to implement in an > efficient fashion, though. It could as simple as providing a variable, gnus-nocem-scorefile. If non-nil, nocem handling in done via score files. Instead of inserting msg-id's in News/NoCeM/cache, insert a "followup" entry in this scorefile. The user is free to have that scorefile used in whatever groups they see fit, using any of the many options gnus provides. I, for example, would add a 'files entry for it in all.SCORE. The nice thing of doing it this way is that I can run a -batch nocem process w/o ever having to worry about coming up with lightweight locking for NoCeM/active. Do a score file cache flush and you have the latest scorefile. Of course, if the user ever decides to use that scorefile in another context, all bets are off. Hmm, to address David's worry about the size of the resulting scorefile: if this method remains as simple as only allowing score entries of one type (it might be followup or subject, but fixed), we can even do it w/o changing the format of NoCeM/active. We'd need to add some form of score-file handler hook that lets us treat that file as a normal scorefile and massage it's data into normal score format at the time it gets read into the score cache -- not hard or time intensive, each entry is of the same format. Note that not treating it as a scorefile would mean all types of kluges to allow concurrent -batch access and would be a lose, IMO. Enough fantasizing for today. Later, -Sudish