On Thu, 10 Sep 2009 22:55:03 +0300 Teemu Likonen <[email protected]> wrote:
TL> On 2009-09-10 20:18 (+0200), Adam Sjøgren wrote: >> If you set the variable I introduced, unregistering happens whenever >> spam.el changes something from spam to ham, or from ham to spam before >> it learns it again - as far as I can see (that is what happens on my >> machine anyway). >> * An email is detected as spam, but you realize that it isn't. You mark >> it as ham. spam.el unregisters it from spam and relearns it as ham. >> >> (And the other way around.) TL> Thanks. I wonder, though, what's the purpose of that TL> spam-unregister-on-reregister variable? Shouldn't it be always turned on TL> (non-nil)? Just to make a point: generally when the meaning of variable TL> starts to sounds like TL> (setq please-fix-this-stupid-bug t) TL> then why not just unconditionally fix the bug and not introduce any new TL> variables to confuse users? We'll let you and others try it out and tell us if it works properly. I agree with Adam, I try not to introduce changes to well-known libraries, even if it seems like a good idea, without making them optional. I wouldn't call the current behavior buggy, just badly designed (the problem is with the general tracking of articles by spam.el). TL> Of course I may have missed something. No offense meant; I'm really on TL> the "thank you" side here. :-) I would love to give you a working spam2.el soon, but it will probably be next year. Meanwhile it's probably a good idea for me to touch spam.el as little as possible and instead gather user opinions and suggestions for spam2.el. cc-ing Ding list in case others have opinions on this :) Ted _______________________________________________ info-gnus-english mailing list [email protected] http://lists.gnu.org/mailman/listinfo/info-gnus-english
