bug in spam.el and expiry issue

bug in spam.el and expiry issue

[Bruce Stephens]

First the typo:

Index: spam.el
===================================================================
RCS file: /usr/local/cvsroot/gnus/lisp/spam.el,v
retrieving revision 6.54
diff -u -r6.54 spam.el
--- spam.el     2003/01/16 12:08:15     6.54
+++ spam.el     2003/01/18 17:53:56
@@ -275,7 +275,7 @@
   (spam-group-processor-p group 'gnus-group-ham-exit-processor-ifile))
 
 (defun spam-group-ham-processor-bogofilter-p (group)
-  (spam-group-processor-p group 'gnus-group-ham-exit-processor-ifile))
+  (spam-group-processor-p group 'gnus-group-ham-exit-processor-bogofilter))
 
 (defun spam-group-spam-processor-stat-p (group)
   (spam-group-processor-p group 'gnus-group-spam-exit-processor-stat))


Secondly, how do I sanely use spam.el with auto-expire (or
total-expire)?  It seems that spam gets categorised OK, but the ham
never gets processed, since (presumably) by the time the check
happens, it's marked with E, which is correctly not processed.

Re: bug in spam.el and expiry issue

[Ted Zlatanov]

On Sat, 18 Jan 2003, bruce+usenet@cenderis.demon.co.uk wrote:
> First the typo:

Thanks, fixed.

> Secondly, how do I sanely use spam.el with auto-expire (or
> total-expire)?  It seems that spam gets categorised OK, but the ham
> never gets processed, since (presumably) by the time the check
> happens, it's marked with E, which is correctly not processed.

Ham will only get processed in ham groups, are you sure you are in a
ham group and have a ham processor defined?  The processing should
happen before the expired-mark is applied, but I have not tested that
particular setup, so if you could check and let me know, I'd
appreciate it.  I may have to modify the behavior of total and auto
expiry a little when spam.el hooks into the summary exit, if the
expiry happens before spam-summary-prepare-exit is invoked.

Ted

Re: bug in spam.el and expiry issue

[Bruce Stephens]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Sat, 18 Jan 2003, bruce+usenet@cenderis.demon.co.uk wrote:

[...]

>> Secondly, how do I sanely use spam.el with auto-expire (or
>> total-expire)?  It seems that spam gets categorised OK, but the ham
>> never gets processed, since (presumably) by the time the check
>> happens, it's marked with E, which is correctly not processed.
>
> Ham will only get processed in ham groups, are you sure you are in a
> ham group and have a ham processor defined?

Hmm.  I'm pretty sure, but I'll recheck.

> The processing should happen before the expired-mark is applied, but
> I have not tested that particular setup, so if you could check and
> let me know, I'd appreciate it.  I may have to modify the behavior
> of total and auto expiry a little when spam.el hooks into the
> summary exit, if the expiry happens before spam-summary-prepare-exit
> is invoked.

It's probably not important that auto-expiry work (indeed, I don't
think it's possible, since auto-expiry marks things for expiry as soon
as you read them).  But total-expire really does need to work, since I
suspect most people who use gnus for email will have most groups set
to total-expire (indeed, the manual suggests that that's true).

Re: bug in spam.el and expiry issue

[Ted Zlatanov]

On Wed, 22 Jan 2003, bruce+usenet@cenderis.demon.co.uk wrote:
> Ted Zlatanov <tzz@lifelogs.com> writes:
> 
>> On Sat, 18 Jan 2003, bruce+usenet@cenderis.demon.co.uk wrote:
> 
> [...]
> 
>>> Secondly, how do I sanely use spam.el with auto-expire (or
>>> total-expire)?  It seems that spam gets categorised OK, but the
>>> ham never gets processed, since (presumably) by the time the check
>>> happens, it's marked with E, which is correctly not processed.
>>
>> The processing should happen before the expired-mark is applied,
>> but I have not tested that particular setup, so if you could check
>> and let me know, I'd appreciate it.  I may have to modify the
>> behavior of total and auto expiry a little when spam.el hooks into
>> the summary exit, if the expiry happens before
>> spam-summary-prepare-exit is invoked.
> 
> It's probably not important that auto-expiry work (indeed, I don't
> think it's possible, since auto-expiry marks things for expiry as
> soon as you read them).  But total-expire really does need to work,
> since I suspect most people who use gnus for email will have most
> groups set to total-expire (indeed, the manual suggests that that's
> true).

With the following group parameters:

((total-expire . t)
 (spam-contents gnus-group-spam-classification-ham)
 (spam-process
  (gnus-group-ham-exit-processor-whitelist))
 (expiry-wait . immediate)
 (expiry-target . "temporarygroup"))

I get ham-marked articles processed into the whitelist at summary
exit, before they are moved to "temporarygroup".  This is the expected
correct behavior.

If you are observing something different, could you show the group
parameters?  Make sure to set them explicitly, not through the regex
facilities - best create a new group and do `G c' on it.

Ted

Re: bug in spam.el and expiry issue

[Bruce Stephens]

Ted Zlatanov <tzz@lifelogs.com> writes:

[...]

> With the following group parameters:
>
> ((total-expire . t)
>  (spam-contents gnus-group-spam-classification-ham)
>  (spam-process
>   (gnus-group-ham-exit-processor-whitelist))
>  (expiry-wait . immediate)
>  (expiry-target . "temporarygroup"))
>
> I get ham-marked articles processed into the whitelist at summary
> exit, before they are moved to "temporarygroup".  This is the expected
> correct behavior.

I get the expected behaviour now.  Probably I just messed up, and was
still using the version where the bogofilter ham setting was
predicated on ifile.  Anyway, it works now, which is wonderful.

(Thanks for pointing out expiry-target, BTW.  I didn't know that
functionality existed.)