From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/48892 Path: main.gmane.org!not-for-mail From: David Z Maze Newsgroups: gmane.emacs.gnus.general Subject: Re: Trouble with spam.el and ifile Date: Tue, 07 Jan 2003 17:32:31 -0500 Sender: owner-ding@hpc.uh.edu Message-ID: References: <4nadic3fo1.fsf@lockgroove.bwh.harvard.edu> <4n1y3owr50.fsf@lockgroove.bwh.harvard.edu> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1041978754 25671 80.91.224.249 (7 Jan 2003 22:32:34 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 7 Jan 2003 22:32:34 +0000 (UTC) Return-path: Original-Received: from malifon.math.uh.edu ([129.7.128.13]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18W2Gt-0006fk-00 for ; Tue, 07 Jan 2003 23:32:31 +0100 Original-Received: from sina.hpc.uh.edu ([129.7.128.10] ident=lists) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 18W2HF-0004ZM-00; Tue, 07 Jan 2003 16:32:53 -0600 Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Tue, 07 Jan 2003 16:33:46 -0600 (CST) Original-Received: from sclp3.sclp.com (sclp3.sclp.com [66.230.238.2]) by sina.hpc.uh.edu (8.9.3/8.9.3) with SMTP id QAA12115 for ; Tue, 7 Jan 2003 16:33:33 -0600 (CST) Original-Received: (qmail 3275 invoked by alias); 7 Jan 2003 22:32:35 -0000 Original-Received: (qmail 3270 invoked from network); 7 Jan 2003 22:32:35 -0000 Original-Received: from pacific-carrier-annex.mit.edu (18.7.21.83) by 66.230.238.6 with SMTP; 7 Jan 2003 22:32:35 -0000 Original-Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id RAA10299 for ; Tue, 7 Jan 2003 17:32:33 -0500 (EST) Original-Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id RAA25796; Tue, 7 Jan 2003 17:32:32 -0500 (EST) Original-Received: from multics.mit.edu (MULTICS.MIT.EDU [18.187.1.73]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id RAA26798; Tue, 7 Jan 2003 17:32:32 -0500 (EST) Original-To: ding@gnus.org In-Reply-To: <4n1y3owr50.fsf@lockgroove.bwh.harvard.edu> (Ted Zlatanov's message of "Tue, 07 Jan 2003 17:07:23 -0500") User-Agent: Gnus/5.090011 (Oort Gnus v0.11) XEmacs/21.4 (Artificial Intelligence, sparc-sun-solaris2.8) Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:48892 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:48892 Ted Zlatanov writes: > On Tue, 07 Jan 2003, dmaze@MIT.EDU wrote: >> Is this right? > > Yes. It says "mail.misc.spam is a spam group; all my groups should be > spam-processed with ifile; all spam articles should be moved to > mail.misc.spam after spam proecsssing; all my incoming spam should be > filtered, through ifile, into mail.misc.spam." Okay, good, that's what I want. >> It should be clearer in the documentation/Customize descriptions >> where you need the backend prefix and where you don't. > > Yeah, the docs need work for sure. I've been trying to get the > package functionality in place first. Everything seems to be matched against gnus-newsgroup-name, FWIW, which does include the backend prefix; since regular expression matching generally matches substrings, though, it's probably okay to either have it or not. > See if that triggers the ifile spam processing on summary exit. You > must have some spam-marked articles. You can test the processing > manually with M-: (spam-summary-prepare-exit) - that's the function > that gets invoked at summary exit. spam-summary-prepare-exit, eh? That has ;; Only for spam groups, we expire and maybe move articles (when (spam-group-spam-contents-p gnus-newsgroup-name) (spam-mark-spam-as-expired-and-move-routine (gnus-parameter-spam-process-destination gnus-newsgroup-name))) ...but that seems to be the opposite behavior from what I expect, I want spam to be shuffled into a spam group only if the current group isn't one. But if I understand the function: spam-marked articles are noted by the spam backend, then spam-marked articles are refiled, then in ham groups, the remaining articles are noted as ham by the spam backend. >> If I mark an article not-spam in the spam group, does it get refiled >> to the next best group on exit? > > No. You have to move it manually (but that functionality could be > added). I assume you mean "mark unread," since there is no not-spam > mark. Mark unread would work; "any ham mark" or "any not-spam mark" might make sense too. It sounds like this is falling into "feature request" land, though. >> (This is especially true for spam-stat; doing this classification >> entirely in elisp looks like it might be a big performance win over >> ifile, > > I haven't tested the performance, but ifile definitely has better > lexing than spam-stat according to the documentation. It looks like ifile reads its database, processes a single message, and writes its database; lather, rinse, repeat. If you're dealing with a networked filesystem, reading and writing the database once per message is a big lose. I've heard rumors that moving ~/.idata to local disk improvies this. Doing filtering inside Emacs means that the database can live in memory until I do a save in Gnus. -- David Maze dmaze@mit.edu http://www.mit.edu/~dmaze/ "Theoretical politics is interesting. Politicking should be illegal." -- Abra Mitchell