spam.el version 3

spam.el version 3

[Ted Zlatanov]

[-- Attachment #1: Type: text/plain, Size: 3228 bytes --]

I am done developing the new version of spam.el, version 3.

Version 1 was the original.  Version 2 was my rewrite.  I think I've
learned a lot about Emacs Lisp since version 1, so version 3 is
better in many ways.

The changes are exclusively in spam.el and they're so major, I'm
attaching the whole thing.  The gnus.el patch below is simply a
customization change, since the spam-use-ham-copy ham processor has
been replaced.  Since spam-use-ham-copy is gone, whoever is using it
will have to switch to (ham spam-use-copy) instead.  I don't want to
support spam-use-ham-copy backwards because it's completely out of
line with the version 3 naming, and it was a (useful) hack anyway.

So, what's new?  Most of the changes are internal.  I've made it MUCH
easier to add a new backend.  It's still not as easy as I would like,
because I don't know how to redo the gnus.el group/topic parameter
definitions when a new backend is added.  But it's much less work
than before.

Spam/ham moving and copying are now done in several default behaviors
which can be overridden (see spam-summary-exit-behavior).  In other
words, if you set the (ham spam-use-move) processor on a group, it
WILL override whatever behavior is selected, but usually you'll get
the right behavior by default.  Consequently, I've eliminated several
unsightly variables that deal with moving spam/ham out of various
types of groups.

The way I implement ham/spam copy/move operations may look strange,
but I thought about it and adding the spam-use-copy and spam-use-move
backends with their associated operations was a cleaner solution than
pretty much anything else.

If you don't use folding-mode, you won't notice the new look of
spam.el much.  With folding-mode, however, it's *really* easy to see
the portions of interest so I'd like to keep the folding marks.

I encourage you all to test spam.el version 3.  It will be the new
version soon, so testing it now and giving me feedback will help
everyone.

Thanks
Ted

gnus.el patch:

Index: gnus.el
===================================================================
RCS file: /usr/local/cvsroot/gnus/lisp/gnus.el,v
retrieving revision 7.23
diff -r7.23 gnus.el
1917a1918,1926
>           (const :tag "Spam: Copy"          
>                  (spam spam-use-copy))
>           (const :tag "Spam: Move (NOTE: NOT NEEDED BY DEFAULT)" 
>                  (spam spam-use-move))
>           (const :tag "Ham: Copy"           
>                  (ham spam-use-copy))
>           (const :tag "Ham: Move (NOTE: NOT NEEDED BY DEFAULT)" 
>                  (ham spam-use-move))
> 
1931d1939
<           (const :tag "Ham: Copy"           (ham spam-use-ham-copy))
1967a1976,1984
>                  (const :tag "Spam: Copy"           
>                         (spam spam-use-copy))
>                  (const :tag "Spam: Move (NOTE: NOT NEEDED BY DEFAULT)" 
>                         (spam spam-use-move))
>                  (const :tag "Ham: Copy"            
>                         (ham spam-use-copy))
>                  (const :tag "Ham: Move (NOTE: NOT NEEDED BY DEFAULT)" 
>                         (ham spam-use-move))
> 
1981d1997
<                  (const :tag "Ham: Copy"           (ham spam-use-ham-copy))


[-- Attachment #2: spam.el --]
[-- Type: application/emacs-lisp, Size: 95543 bytes --]

Re: spam.el version 3

[Tim Brown]

>>>>> "Ted" == Ted Zlatanov <tzz@lifelogs.com> writes:

    > I am done developing the new version of spam.el, version 3.
    > Version 1 was the original.  Version 2 was my rewrite.  I think
    > I've learned a lot about Emacs Lisp since version 1, so version
    > 3 is better in many ways.

Good stuff.  One thing i'm curious about is whether or not is the
blackholes specification.  It appears this is driven by regex; am I
just silly, or can we get CIDR-style entries as well?  

For example: 10.0.0.0/8

Tim

Re: spam.el version 3

[Ted Zlatanov]

On Mon, 14 Jun 2004, tim@tux.org wrote:

>>>>>> "Ted" == Ted Zlatanov <tzz@lifelogs.com> writes:

> Good stuff.  One thing i'm curious about is whether or not is the
> blackholes specification.  It appears this is driven by regex; am I
> just silly, or can we get CIDR-style entries as well?  
> 
> For example: 10.0.0.0/8

I'm not sure I understand.  What would netblocks do?

Ted