Add hooks to Gnus on move/edit/delete?

Add hooks to Gnus on move/edit/delete?

[Kai Großjohann]

I've just started using ifile together with Jeremy's wonderful
ifile-gnus.el.  It really rocks.

But of course it doesn't make much sense to advise the nnml
functions, instead we would like to provide hooks that can be called
when articles are moved.

So what do people think about adding said hooks?  I'd do a
gnus-request-move-article-hook, gnus-request-accept-article-hook, and
gnus-request-replace-article-hook.  Or should these be *-functions,
and some args should be passed to the functions?  What args?

I don't quite understand the meaning/purpose of the
nnmail-article-group advice, though.

The new variables could also be used for maintaining the
.nnmail-cache file, I think.  I wonder whether it's a good idea to
use them for this purpose.

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

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

[Jeremy H. Brown]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
> I've just started using ifile together with Jeremy's wonderful
> ifile-gnus.el.  It really rocks.

Thanks for the kind words!

> But of course it doesn't make much sense to advise the nnml
> functions, instead we would like to provide hooks that can be called
> when articles are moved.

Absolutely agreed.  The advice is very much just a hack to make it
work with the stable distributions; I only went that route after
determining that the hooks didn't (yet) exist.

> I don't quite understand the meaning/purpose of the
> nnmail-article-group advice, though.

ifile-gnus is set up to do two things:
- provide a recommendation to you to use during splits
- record your actual decision, whether or not it was what ifile
  recommended

The nnmail-article-group advice works on both problems.

First, it sticks the article buffer in the variable
"ifile-article-buffer"; the ifile functions that you use in the split
rely on this variable to hide the fact that, as discussed here
recently, the actual name of the buffer varies depending on how the
nnmail-article-group is entered (initial split or respooling or
whatever).

Second, after the split has been performed, the advice runs ifile
record the actual split decision made.

Jeremy

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

[Kai Großjohann]

jhbrown@ai.mit.edu (Jeremy H. Brown) writes:

> Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
>
>> I don't quite understand the meaning/purpose of the
>> nnmail-article-group advice, though.
>
> ifile-gnus is set up to do two things:
> - provide a recommendation to you to use during splits
> - record your actual decision, whether or not it was what ifile
>   recommended
>
> The nnmail-article-group advice works on both problems.
>
> First, it sticks the article buffer in the variable
> "ifile-article-buffer"; the ifile functions that you use in the split
> rely on this variable to hide the fact that, as discussed here
> recently, the actual name of the buffer varies depending on how the
> nnmail-article-group is entered (initial split or respooling or
> whatever).

Ah, so when Gnus is changed to record the buffer name in a variable,
then part of the need goes away.

> Second, after the split has been performed, the advice runs ifile
> record the actual split decision made.

And what to do about the other half?  What would be the right way to
remove the need for that half?

Are you willing to work on the proper integration of ifile into Gnus,
and would you sign the necessary papers for inclusion in Gnus?

kai

PS: It might be good to use message instead of print to provide
    debugging messages.
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

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

[Jeremy H. Brown]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
> Ah, so when Gnus is changed to record the buffer name in a variable,
> then part of the need goes away.

Yep.

> > Second, after the split has been performed, the advice runs ifile
> > record the actual split decision made.
> 
> And what to do about the other half?  What would be the right way to
> remove the need for that half?

Interesting question.  Perhaps a gnus-split-decision-hook whose
functions were called with the final split decision?

One other technical issue to try to resolve gracefully: gnus rudely
mutates the article text *after* the split decision by inserting the
Xref header; this means that ifile actually gets trained on a slightly
different text than is stored or used when you refile, say.  What's
the Right Way to deal with this so that ifile always sees the same
message?  I don't want to chuck headers in general, since there're
often useful bits in there.

> Are you willing to work on the proper integration of ifile into Gnus,
> and would you sign the necessary papers for inclusion in Gnus?

I think so.

Questions:
- What, exactly, is the paperwork?  (URL?)
- Should this really be a distinct module from the spam*.el stuff, or
  should we merge the functionality in some fashion?  I haven't really
  looked at how that stuff works in general, or with the recent
  bogofilter stuff in particular.

Caveats:
- I want to finish working through my TODO list for the stable version
  before I start trying to aim hard for oort.  But I'm happy to chat
  about what hooks are needed.
- I'm not presently an oort user, so I'll need to get up to speed
  there.
- Unless someone decides to pay me, this won't necessarily happen at
  real high speed...

> PS: It might be good to use message instead of print to provide
>     debugging messages.

That's now at the top of the TODO list.

Thanks,
Jeremy

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

[Clemens Fischer]

jhbrown@ai.mit.edu (Jeremy H. Brown) writes:

> Interesting question.  Perhaps a gnus-split-decision-hook whose
> functions were called with the final split decision?

whatever you do:  recording the number of "correct" versus "incorrect"
i-filings is neccessary to later calculate the overall precision.  if
the user does _not_ want this, he should have to specifically disable
this feature.  i keep two simple numbers for this in a simple text
file, which might well not be what everybody wants.

also, i'd prefer another name than *split-decision*, because this
(particle here) has a meaning in english that could mislead starters.

> One other technical issue to try to resolve gracefully: gnus rudely
> mutates the article text *after* the split decision by inserting the
> Xref header; this means that ifile actually gets trained on a slightly
> different text than is stored or used when you refile, say.  What's
> the Right Way to deal with this so that ifile always sees the same
> message?  I don't want to chuck headers in general, since there're
> often useful bits in there.

i really hope, and jason rennie (author of ifile) seems to agree, that
some later version of ifile will have new semantics for the following
options:  (i) `-h headers' and `-H headers', where `headers' will be a
comma separated list of headers to strip (-h) and to keep (-H).

we should also keep in mind that either limited support for (the type
of) MIME-detection might get built into ifile (like you proposed
yourself), or it might even get outfitted with an interface to
metamail.  this might deviate from pipes when mm is used as a
preprocessor in general or for certain content-types only
(configurable!).

-- 
clemens

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

[Jeremy H. Brown]

Clemens Fischer <ino@despammed.com> writes:
> whatever you do:  recording the number of "correct" versus "incorrect"
> i-filings is neccessary to later calculate the overall precision.  if
> the user does _not_ want this, he should have to specifically disable
> this feature.  i keep two simple numbers for this in a simple text
> file, which might well not be what everybody wants.

Some sort of statistics is on the TODO list, but it's relatively low
priority; I don't think the numbers matter to most people so much as
their subjective sense: this is doing an adequate job, or it's not.

(If one is using ifile for more than simply spam/non-spam, the
statistics pile might grow, if you wanted to know, say, false-hit and
false-miss rate for each group.  I havent thought about this hard at
al yet.)

Jeremy

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

[Lars Magne Ingebrigtsen]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> But of course it doesn't make much sense to advise the nnml
> functions, instead we would like to provide hooks that can be called
> when articles are moved.

Yup.  But doesn't it make even more sense to not hook into the mail
backend functions at all, and use spam.el instead?  It seems cleaner
to implement this from the Gnus side instead of using the backend.
However, that might not be the best solution of you're using ifile as
the MTA...

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

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

[Kai Großjohann]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Yup.  But doesn't it make even more sense to not hook into the mail
> backend functions at all, and use spam.el instead?  It seems cleaner
> to implement this from the Gnus side instead of using the backend.
> However, that might not be the best solution of you're using ifile as
> the MTA...

First of all, ifile-gnus.el now uses a different mechanism for
communicating with the backend, and the new mechanism works for more
than one backend.

However, I think that integrating ifile into spam.el is not so good
because ifile can also be used for general mail splitting.  It's
really cool, actually.  Alas, I went back to nnimap so I'm having
trouble using it.
-- 
Ambibibentists unite!

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

[Lars Magne Ingebrigtsen]

kai.grossjohann@uni-duisburg.de (Kai Großjohann) writes:

> First of all, ifile-gnus.el now uses a different mechanism for
> communicating with the backend, and the new mechanism works for more
> than one backend.

Right.

> However, I think that integrating ifile into spam.el is not so good
> because ifile can also be used for general mail splitting.  It's
> really cool, actually.

Oh, I see.  That is quite cool; yes.

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

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

[Ted Zlatanov]

On Sun, 29 Dec 2002, kai.grossjohann@uni-duisburg.de wrote:
> First of all, ifile-gnus.el now uses a different mechanism for
> communicating with the backend, and the new mechanism works for more
> than one backend.

Is this released, and does it work with nnimap?  I haven't followed
ifile-gnus.el, unfortunately, due to lack of time.

> However, I think that integrating ifile into spam.el is not so good
> because ifile can also be used for general mail splitting.  It's
> really cool, actually.  Alas, I went back to nnimap so I'm having
> trouble using it.

Ah, so maybe it doesn't work with imap yet :)

Right now, all the other spam-split functions return spam-split-group
or nil (as a spam/non-spam convention), but IIRC ifile-spam-filter
could filter messages into regular groups as well.  The use of
spam-split-group is just a convention in spam.el.

The spam-check-ifile function is as follows right now:

;;; check the ifile backend; return nil if the mail was NOT classified as spam
(condition-case nil
    (progn
      (require 'ifile-gnus)
        ;;; 
      (defun spam-check-ifile ()
	(let ((ifile-primary-spam-group spam-split-group))
	  (ifile-spam-filter nil))))
  (file-error (setq spam-list-of-checks
		    (delete (assoc 'spam-use-ifile spam-list-of-checks)
			    spam-list-of-checks))))


So if ifile-spam-filter could and should be replaced with another
ifile-gnus.el function that returns regular group names, spam.el can
do all the ifile classification automatically if the user just sets
spam-use-ifile to t.

Does that sound reasonable?

Ted

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

[Kai Großjohann]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Sun, 29 Dec 2002, kai.grossjohann@uni-duisburg.de wrote:
>> First of all, ifile-gnus.el now uses a different mechanism for
>> communicating with the backend, and the new mechanism works for more
>> than one backend.
>
> Is this released, and does it work with nnimap?  I haven't followed
> ifile-gnus.el, unfortunately, due to lack of time.

I think it might work if you use nnimap splitting.  If you use Sieve
or procmail, then it could be difficult, since the ifile database
would be on your local host in the home dir, whereas the
Sieve/procmail rules are on the IMAP server.

> So if ifile-spam-filter could and should be replaced with another
> ifile-gnus.el function that returns regular group names, spam.el can
> do all the ifile classification automatically if the user just sets
> spam-use-ifile to t.
>
> Does that sound reasonable?

I'm not sure.  How do I tell spam.el which group a message is in?  If
ifile has chosen the group wrongly, how do I tell it about the error?

ifile-gnus intercepts move and copy operations to see that.  So
designating a message as spam works by moving it to the spam group.

Maybe a two-stage process is better: first decide whether it's spam
or not, then distribute the non-spam to the right groups.

But then, there is Gmane, which makes a lot of splitting unnecessary :-)

-- 
Ambibibentists unite!

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

[Lars Magne Ingebrigtsen]

kai.grossjohann@uni-duisburg.de (Kai Großjohann) writes:

> I'm not sure.  How do I tell spam.el which group a message is in?  If
> ifile has chosen the group wrongly, how do I tell it about the error?

Quoth the manual:

-----
   Gnus can learn from the spam you get.  All you have to do is collect
your spam in one or more spam groups, and set the variable
`spam-junk-mailgroups' as appropriate.  In these groups, all messages
are considered to be spam by default: they get the `H' mark.  You must
review these messages from time to time and remove the `H' mark for
every message that is not spam after all.  When you leave a spam group,
all messages that continue with the `H' mark, are passed on to the
spam-detection engine (bogofilter, ifile, and others).  To remove the
`H' mark, you can use `M-u' to "unread" the article, or `d' for
declaring it read the non-spam way.  When you leave a group, all `H'
marked articles, saved or unsaved, are sent to Bogofilter or ifile
(depending on `spam-use-bogofilter' and `spam-use-ifile'), which will
study them as spam samples.
-----

So I guess spam.el tells ifile these things upon group exit...

> But then, there is Gmane, which makes a lot of splitting unnecessary :-)

What's that, then?  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

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

[Ted Zlatanov]

On Sun, 29 Dec 2002, kai.grossjohann@uni-duisburg.de wrote:

> I think it might work if you use nnimap splitting.  If you use Sieve
> or procmail, then it could be difficult, since the ifile database
> would be on your local host in the home dir, whereas the
> Sieve/procmail rules are on the IMAP server.

We can explicitly require that in the manual.

>> So if ifile-spam-filter could and should be replaced with another
>> ifile-gnus.el function that returns regular group names, spam.el
>> can do all the ifile classification automatically if the user just
>> sets spam-use-ifile to t.
>>
>> Does that sound reasonable?
> 
> I'm not sure.  How do I tell spam.el which group a message is in?
> If ifile has chosen the group wrongly, how do I tell it about the
> error?

I think it's supposed to be automatic, but currently only bogofilter
processing is done:

- when entering a spam group ( a member of spam-junk-mailgroups),
  all unread messages are marked as spam

- when exiting any group:

  - spam-marked articles are processed as spam, then marked expired so
    they are not processed twice and so we don't keep them around.

  - ham-marked articles are processed as ham (non-spam); these are the
    gnus-del-mark, gnus-read-mark, gnus-killed-mark,
    gnus-kill-file-mark, and gnus-low-score-mark articles.  There
    should be, but isn't, a mechanism to prevent them from being
    processed more than once.  Any suggestions?  Yet another cache or
    a supplemental ham-processed-mark?

When I say "processed," I mean "passed to bogofilter on the command line
with the appropriate flag (-n for ham, -s for spam)."

The equivalent of spam-bogofilter-register-routine for ifile needs to
be written for ifile processing on group summary exit.  I haven't done
it yet, because I didn't know that ifile-gnus.el supported nnimap
already.  So let me know if you think it's ready to be incorporated.

> ifile-gnus intercepts move and copy operations to see that.  So
> designating a message as spam works by moving it to the spam group.

With spam.el, you designate a message as spam by marking it with the
spam mark.  We could automatically move all spam articles in a group
to the spam group on summary exit when ifile is enabled, to accomodate
its operation mode.  But would that be acceptable to users?

> Maybe a two-stage process is better: first decide whether it's spam
> or not, then distribute the non-spam to the right groups.

I'm not sure how that would work.

Ted

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

[Ted Zlatanov]

On Sun, 29 Dec 2002, larsi@gnus.org wrote:
> Quoth the manual:
> 
> -----
>    Gnus can learn from the spam you get.  All you have to do is
>    collect your spam in one or more spam groups, and set the
>    variable `spam-junk-mailgroups' as appropriate.  In these groups,
>    all messages are considered to be spam by default: they get the
>    `H' mark.  You must review these messages from time to time and
>    remove the `H' mark for every message that is not spam after all.
>    When you leave a spam group, all messages that continue with the
>    `H' mark, are passed on to the spam-detection engine (bogofilter,
>    ifile, and others).  To remove the `H' mark, you can use `M-u' to
>    "unread" the article, or `d' for declaring it read the non-spam
>    way.  When you leave a group, all `H' marked articles, saved or
>    unsaved, are sent to Bogofilter or ifile (depending on
>    `spam-use-bogofilter' and `spam-use-ifile'), which will study
>    them as spam samples.  -----
> 
> So I guess spam.el tells ifile these things upon group exit...

I'm afraid I gave incorrect info here, ifile does not yet get the
spam-marked articles.  But I'd rather fix the code than the manual :)
See my other message to Kai.

Ted

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

[Kai Großjohann]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> kai.grossjohann@uni-duisburg.de (Kai Großjohann) writes:
>
>> I'm not sure.  How do I tell spam.el which group a message is in?  If
>> ifile has chosen the group wrongly, how do I tell it about the error?
>
> Quoth the manual:
>[...]
> So I guess spam.el tells ifile these things upon group exit...

Hm.  I'll read it again, but I thought spam.el only distinguished
between spam and ham, not between N different groups.

spam.el can use ifile as a binary classifier, but ifile-gnus.el
allows for using ifile as a multiway classifier.  (Whee.  Does that
make sense?)

-- 
Ambibibentists unite!

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

[Kai Großjohann]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Sun, 29 Dec 2002, kai.grossjohann@uni-duisburg.de wrote:
>
>> Maybe a two-stage process is better: first decide whether it's spam
>> or not, then distribute the non-spam to the right groups.
>
> I'm not sure how that would work.

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.

The above is meant to be a description of the desired behavior, not a
suggestion for the implementation.
-- 
Ambibibentists unite!

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

[Ted Zlatanov]

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

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

[Kai Großjohann]

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 wonder if spam.el needs to tell ifile to use another index file.)
-- 
Ambibibentists unite!

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

[Ted Zlatanov]

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

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

[Nathan J. Williams]

Ted Zlatanov <tzz@lifelogs.com> writes:

> > (I wonder if spam.el needs to tell ifile to use another index file.)
> 
> I don't think so, this should work right away.

You might want to do this for efficency reasons; ifile gets slower as
the number of split categories increases. Having a 2-way split (spam
vs. non-spam) and then an N-way split for non-spam is quite a bit
faster than two N+1-way splits.

(and one of us ifile users should hack in something to cache the DB in
memory, so it doesn't have to read/parse/write the entire DB for every
message).

        - Nathan

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

[Ted Zlatanov]

On 31 Dec 2002, nathanw@MIT.EDU wrote:
> Ted Zlatanov <tzz@lifelogs.com> writes:
> 
>> > (I wonder if spam.el needs to tell ifile to use another index
>> > file.)
>> 
>> I don't think so, this should work right away.
> 
> You might want to do this for efficency reasons; ifile gets slower
> as the number of split categories increases. Having a 2-way split
> (spam vs. non-spam) and then an N-way split for non-spam is quite a
> bit faster than two N+1-way splits.

I have no problem with the idea, but the optimized implementation
should really be on the ifile-gnus.el side, in the function
ifile-spam-filter.  I don't think spam.el should reinvent
ifile-spam-filter, considering that function was specifically written
for spam detection.

Ted

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

[Simon Josefsson]

kai.grossjohann@uni-duisburg.de (Kai Großjohann) writes:

> Ted Zlatanov <tzz@lifelogs.com> writes:
>
>> On Sun, 29 Dec 2002, kai.grossjohann@uni-duisburg.de wrote:
>>> First of all, ifile-gnus.el now uses a different mechanism for
>>> communicating with the backend, and the new mechanism works for more
>>> than one backend.
>>
>> Is this released, and does it work with nnimap?  I haven't followed
>> ifile-gnus.el, unfortunately, due to lack of time.
>
> I think it might work if you use nnimap splitting.  If you use Sieve
> or procmail, then it could be difficult, since the ifile database
> would be on your local host in the home dir, whereas the
> Sieve/procmail rules are on the IMAP server.

It might be possible for ifile-gnus to generate Sieve rules similar to
what the Gnus/Sieve stuff does now.  You would need to upload the
sieve script separately though.

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

[Kai Großjohann]

Simon Josefsson <jas@extundo.com> writes:

> It might be possible for ifile-gnus to generate Sieve rules similar to
> what the Gnus/Sieve stuff does now.  You would need to upload the
> sieve script separately though.

I think Sieve is not Turing complete and therefore a naive Bayesian
classifier cannot be implemented within the confines of Sieve.
-- 
Ambibibentists unite!

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

[Simon Josefsson]

kai.grossjohann@uni-duisburg.de (Kai Großjohann) writes:

> Simon Josefsson <jas@extundo.com> writes:
>
>> It might be possible for ifile-gnus to generate Sieve rules similar to
>> what the Gnus/Sieve stuff does now.  You would need to upload the
>> sieve script separately though.
>
> I think Sieve is not Turing complete and therefore a naive Bayesian
> classifier cannot be implemented within the confines of Sieve.

Right.  I don't really know what ifile-gnus is.  Does it generate Gnus
splitting rules?  Or is it a fancy mail splitter function that is
invoked by Gnus?  If the latter, forget my ramblings.

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

[Kai Großjohann]

Simon Josefsson <jas@extundo.com> writes:

> Right.  I don't really know what ifile-gnus is.  Does it generate Gnus
> splitting rules?  Or is it a fancy mail splitter function that is
> invoked by Gnus?  If the latter, forget my ramblings.

ifile-gnus invokes the external program ifile on the message.  ifile
is a Naive Bayesian classifier.  That means you show it some example
messages with their categories (1 group = 1 category), and from these
it learns.  Afterwards you can invoke it on a new message and it will
print a category for this message, using the previously learned data.

Naive Bayes is not the best text classifier you can get.  Experiments
show that good classifiers can achieve 80% accuracy (or so).

The spam identification suggestion by Paul Graham implements Naive
Bayes in Lisp.
-- 
Ambibibentists unite!