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

[Ted Zlatanov <tzz@lifelogs.com>]

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?  It seems awkward to try to make spam.el sort mail
in a way that it wasn't intended to do.  I think I'd like to keep
functions invoked by spam-split standardized, returning either
spam-split-group or nil.  Currently, spam-check-ifile does that:

	(let ((ifile-primary-spam-group spam-split-group))
	  (ifile-spam-filter nil))))

I think that standardization would make life easier in the long run.
Do you or anyone else think we should have spam.el do general mail
sorting?

Also, the following is at Jeremy Brown's ifile-gnus.el page at
http://www.ai.mit.edu/people/jhbrown/ifile-gnus.html:

"THIS IS ALPHA-QUALITY SOFTWARE. IT MAY EAT YOUR EMAIL. IT MAY CORRUPT
YOUR GNUS CONFIGURATION. IT MAY DO OTHER UNPLEASANT THINGS TO YOUR
COMPUTER. I'M NOT KIDDING."

Considering that and the lack of support for nnimap, I'm not sure how
much work I should put into ifile-gnus.el support now instead of
later, when the code is more beta- than alpha-quality.  I'm not
implying that ifile-gnus.el is buggy, only that it may change
significantly with the next release.  Maybe Jeremy could give us an
update :)

Ted