Re: ifile-gnus: Add hooks to Gnus on move/edit/delete?

[Ted Zlatanov <tzz@lifelogs.com>]

On Tue, 31 Dec 2002, kai.grossjohann@uni-duisburg.de wrote:
> Ted Zlatanov <tzz@lifelogs.com> writes:
> 
>> On Mon, 30 Dec 2002, kai.grossjohann@uni-duisburg.de wrote:
>>> Well, nnmail-split-methods (or nnmail-split-fancy) could use
>>> spam.el to put spam messages into a special group.  spam.el could
>>> invoke ifile, telling it to use ~/.idata.spam.  After this,
>>> `normal' ifile-gnus processing could be done on the remaining ham.
>>
>> On second thought, why not have something like 
>>
>> (: spam-split)
>> (: ifile-split)
>>
>> in the split rules?
> 
> That might implement my suggestion.  I haven't tried it :-)  If it
> works, it's a really good idea.

I think it should, no reason why not.  The ifile invocation inside
spam-split is binary.  We invoke ifile-spam-filter with 'nil' as the
other-split parameter, and we set ifile-primary-spam-group to
spam-split-group; this means that only spam-split-group or nil will be
returned.

(defun ifile-spam-filter (other-split)
  (if (and ifile-active (equal (ifile-recommend) "spam"))
      ifile-primary-spam-group
    other-split))

So just add this (sorry, no ifile-split exists)

  (: ifile-recommend)

after (: spam-split) in your nnmail split rules and turn ifile on.
The penalty is that you invoke ifile twice for each article.

As I said, I want to wait until the ifile interface is stable before I
have spam.el support it for summary exit processing of spam.  I hope
that's OK with everyone.  Right now, you can manually move spam-marked
articles to your spam-split-group, and ifile-gnus.el will understand
that you want them to be considered spam.

> (I wonder if spam.el needs to tell ifile to use another index file.)

I don't think so, this should work right away.

Ted