From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/57868 Path: main.gmane.org!not-for-mail From: "Ted Zlatanov" Newsgroups: gmane.emacs.gnus.general Subject: Re: Improving the spam.el documentation. Date: 7 Jun 2004 13:06:08 -0400 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Sender: ding-owner@lists.math.uh.edu Message-ID: <4nr7srpabj.fsf@lifelogs.com> References: <87smdk8yxs.fsf@enki.rimspace.net> <4nfz9kecvc.fsf@lifelogs.com> <8765ac3elm.fsf@enki.rimspace.net> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1086629083 21453 80.91.224.253 (7 Jun 2004 17:24:43 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 7 Jun 2004 17:24:43 +0000 (UTC) Cc: ding@gnus.org Original-X-From: ding-owner+M6409@lists.math.uh.edu Mon Jun 07 19:24:28 2004 Return-path: Original-Received: from malifon.math.uh.edu ([129.7.128.13]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BXNrH-0001VM-00 for ; Mon, 07 Jun 2004 19:24:27 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by malifon.math.uh.edu with smtp (Exim 3.20 #1) id 1BXNqt-0003Vq-00; Mon, 07 Jun 2004 12:24:03 -0500 Original-Received: from util2.math.uh.edu ([129.7.128.23]) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 1BXNqm-0003Vk-00 for ding@lists.math.uh.edu; Mon, 07 Jun 2004 12:23:56 -0500 Original-Received: from justine.libertine.org ([66.139.78.221] ident=postfix) by util2.math.uh.edu with esmtp (Exim 4.30) id 1BXNql-0006LI-89 for ding@lists.math.uh.edu; Mon, 07 Jun 2004 12:23:55 -0500 Original-Received: from mail.bwh.harvard.edu (sysblade0.bwh.harvard.edu [134.174.9.44]) by justine.libertine.org (Postfix) with ESMTP id CD5463A003B for ; Mon, 7 Jun 2004 12:23:54 -0500 (CDT) Original-Received: (qmail 24178 invoked from network); 7 Jun 2004 17:17:50 -0000 Envelope-Sender: tzz@lifelogs.com Envelope-Recipients: daniel@rimspace.net, ding@gnus.org, Original-Received: from asimov.bwh.harvard.edu (HELO asimov) ([134.174.9.63]) (envelope-sender ) by mail.bwh.harvard.edu (qmail-ldap-1.03) with SMTP for ; 7 Jun 2004 17:17:49 -0000 Mail-Followup-To: "Daniel Pittman" , ding@gnus.org Original-To: "Daniel Pittman" X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6;d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" In-Reply-To: <8765ac3elm.fsf@enki.rimspace.net> (Daniel Pittman's message of "Mon, 31 May 2004 23:34:13 +1000") User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Precedence: bulk Xref: main.gmane.org gmane.emacs.gnus.general:57868 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:57868 On Mon, 31 May 2004, daniel@rimspace.net wrote: > -First, some hooks will get installed by @code{spam-initialize}. There > +First, some hooks will get installed by @code{spam-initialize}. There I thought there were always two spaces after a period. Is Texinfo different? > +@c Is the registry stuff really not documented anywhere? I couldn't find > +@c anything. --daniel@rimspace.net It's not, unfortunately I haven't had time to write that documentation. There is some documentation at the beginning of gnus-registry.el, but that's all I've done. > -You can also give @code{spam-split} a parameter, > -e.g. @code{spam-use-regex-headers} or @code{"maybe-spam"}. Why is > -this useful? > +mail considered to be spam into the group on the current server given by > +the variable @code{spam-split-group}; by default that is the @samp{spam} > +group. > + > +@c REVIST: Do we actually need to go into this here? --daniel@rimspace.net > +This group name must be @emph{unqualified} name; fancy splitting cannot > +send mail to another back-end during the split process, so setting > +@code{spam-split-group} to a qualified name will result in that full > +string being used as the destination group. > + > +You can also give @code{spam-split} a parameter, e.g. > +@code{spam-use-regex-headers} or @code{"maybe-spam"}. Why is this > +useful? Feel free to move this information, but I think it needs to be stated somewhere. The extra parameters to spam-split can make it very useful for all kinds of strange setups. (s/REVIST/REVISIT/) > +@c REVISIT: this really should be more detailed about this. > +@c can we either make these just work(tm), or document it without the > +@c "but maybe it will work anyway" bit? > You should still have specific checks such as > -@code{spam-use-regex-headers} set to @code{t}, even if you > -specifically invoke @code{spam-split} with the check. The reason is > -that when loading @file{spam.el}, some conditional loading is done > -depending on what @code{spam-use-xyz} variables you have set. This > -is usually not critical, though. > +@code{spam-use-regex-headers} set to @code{t}, even if you specifically > +invoke @code{spam-split} with the check. The reason is that when loading > +@file{spam.el}, some conditional loading is done depending on what > +@code{spam-use-xyz} variables you have set. This is usually not > +critical, though. Right now, these Just Work (tm) but I think it's nice to mention it. Overall a very nice job, I think it should go into CVS. I'd like one other person to review the patch, though, due to its size. Thanks Ted