(Filtering Spam Using The Spam ELisp Package): added

example of using a string as a parameter to spam-split in order
to override the default spam-split-group value

diff --git a/texi/ChangeLog b/texi/ChangeLog
index 58c8da3..58591ff 100644 (file)
--- a/texi/ChangeLog
+++ b/texi/ChangeLog
@@ -1,3 +1,9 @@
+2003-10-27  Teodor Zlatanov  <tzz@lifelogs.com>
+
+       * gnus.texi (Filtering Spam Using The Spam ELisp Package): added
+       example of using a string as a parameter to spam-split in order
+       to override the default spam-split-group value
+
 2003-10-27  Jesper Harder  <harder@ifa.au.dk>
 
        * gnusref.tex (subsection*{Notes}): do.

diff --git a/texi/gnus.texi b/texi/gnus.texi
index 3ca02eb..06453db 100644 (file)
--- a/texi/gnus.texi
+++ b/texi/gnus.texi
@@ -22484,7 +22484,8 @@ mail considered to be spam into the group name given by the variable
 but you can customize @code{spam-split-group}.
 
 You can also give @code{spam-split} a parameter,
-e.g. @samp{'spam-use-regex-headers}.  Why is this useful?
+e.g. @samp{'spam-use-regex-headers} or @samp{"maybe-spam"}.  Why is
+this useful?
 
 Take these split rules (with @code{spam-use-regex-headers} and
 @code{spam-use-blackholes} set):
@@ -22510,15 +22511,18 @@ regex-headers check) will be after the ding rule:
 
 @example
  nnimap-split-fancy '(|
-                     (: spam-split 'spam-use-regex-headers)
+;;; all spam detected by spam-use-regex-headers goes to "regex-spam"
+                     (: spam-split "regex-spam" 'spam-use-regex-headers)
                      (any "ding" "ding")
+;;; all other spam detected by spam-split goes to spam-split-group
                      (: spam-split)
                      ;; default mailbox
                      "mail")
 @end example
 
 Basically, this lets you invoke specific @code{spam-split} checks
-depending on your particular needs.  You don't have to throw all mail
+depending on your particular needs, and to target the results of those
+checks to a particular spam group.  You don't have to throw all mail
 into all the spam tests.  Another reason why this is nice is that
 messages to mailing lists you have rules for don't have to have
 resource-intensive blackhole checks performed on them.  You could also