Re: How to use the spam.el package?

[Ted Zlatanov <tzz@lifelogs.com>]

On Mon, 03 Nov 2003, kai@emptydomain.de wrote:
> Hm.  Ooops.  But what about spam-install-hooks?  That seems to be
> set to something depending on spam-use-foo upon loading spam.el, so
> if I call spam-initialize first, then frob spam-use-foo, then it's
> too late.  So I'll also have to set spam-install-hooks, right?

You used to have to do it.  The new way is to just call the
autoloaded spam-initialize, which will (we hope) do everything
properly, and if it doesn't it will be fixed.

> *blush*

It's really OK to have these questions - as you can see, you've
already pointed out several problems or unclear spots in the docs.

>>> * I wasn't sure that just setting the processor to nil was the
>>>   right thing to do, I was just operating on a hunch that it might
>>>   work.  How about making this explicit, too?
>>
>> Why?  It makes perfect sense that if you don't explicitly set a
>> processor, there won't be one.  I don't want to confuse the users
>> more than they need to be :)
> 
> Well, spam is being processed by Bogofilter in my case.  Or, put
> another way, the processing I do on spam is to move it to
> INBOX.spam.

OK, how would you suggest I change the docs and/or implementation?  I
understand the problem, I'm just not sure how I can fix it.

>>> * I would also appreciate some tutorial kind of advice, like
>>>   saying for the following common situation, this is how you set
>>>   the variables.  It's difficult to figure out how it all ties
>>>   together: you have to read all of the main node on spam.el and
>>>   /understand/ it, too, if you want to configure things.
>>
>> Sure.  I welcome any contributions in that direction.  Integration
>> of spam.el with the registry plus making the registry work properly
>> in all cases are higher on my priority list.
> 
> Ah, yes, I should have expected the please-do-it answer ;-)
> Sorry that I didn't just do it in the first place, but came here
> whining instead.

You misunderstood, I'm not opposed to writing the tutorials myself,
and in fact I probably will if no one else does.  I just want to
finish what I consider essential functionality first, in time for the
new Gnus release I hope.

>>> * How do I tell spam.el that messages from nnimap:INBOX.spam and
>>>   nnimap:INBOX.makespam don't need to be frobbed further?  I'm
>>>   afraid they'll be subjected to gnus-spam-process-destinations...
>>
>> If the messages in those groups are marked as spam, they will be
>> moved to the spam-process-destination whether there is or isn't a
>> spam processor.  So don't set a spam-process-destination if you
>> don't want one, ditto for the spam-processor.  Is that what you're
>> asking?
> 
> I want spam to be moved to INBOX.spam.  But it doesn't make sense
> (IMHO) to move messages from INBOX.spam to INBOX.spam.  I see an
> infloop lurking there.

Nah, we move message by unique article number, not message ID.  The
new articles that were just moved in are not automatically integrated
in the loop, so it will end when the old articles are all moved.  It
should work.  I wouldn't recommend it, but for pure obfuscated fun
it's hard to beat it.

Ted