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

[jhbrown@ai.mit.edu (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