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

[Clemens Fischer <ino@despammed.com>]

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