Re: Improving the spam.el documentation.

["Ted Zlatanov" <tzz@lifelogs.com>]

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