Re: Trouble with spam.el and ifile

[David Z Maze <dmaze@MIT.EDU>]

Ted Zlatanov <tzz@lifelogs.com> 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