Re: Trouble with spam.el and ifile

[Ted Zlatanov <tzz@lifelogs.com>]

On Tue, 07 Jan 2003, dmaze@MIT.EDU wrote:
> 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.

...except for spam-split-group (which, when set to "mail" for
instance, may mean "nnimap:mail" or "nnml:mail" because of the way
splits work).  Also spam-junk-mailgroups is a list of names, not
regexes.  I didn't convert it to regexes because there's already a
mechanism, through the spam-contents parameter, to specify a group is
spam through a regex.


> 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.

The behavior made sense to me at the time, but I see what you mean and
my original thought was wrong.  Perhaps it should be either reversed
to apply to groups that are not spam (ham + unclassified), or *all*
groups should have their spam-marked articles processed by
spam-mark-spam-as-expired-and-move-routine.  Should I pick one or the
other, or make it yet another user option?

>>> 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.

Well, it can be added, and it makes sense as well - you don't want ham
articles in a spam group.  Maybe Yet Another User Option.

> 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.  

The code is much simpler when you deal with one message at a time.
That can be fixed, but take a look at the bogofilter register routine
which does multiple messages to see why it may be a little complex.
Hmm, maybe I can have the registration routine take a process as an
optional parameter.

> I've heard rumors that moving ~/.idata to local disk improvies this.

Maybe Yet Another User Option to customize the .idata file name for
spam.el use of ifile...  That's an easy one to add, and I can imagine
people might want to keep spam.el's ifile .idata and their regular
.idata separate as well.

> Doing filtering inside Emacs means that the database can live in
> memory until I do a save in Gnus.

You mean spam-stat.el?  Yes, but ifile's lexer is supposed to be
better.  I don't have performance numbers in terms of speed or spam
detection percentages, though.

Ted