[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: spam2.el

From: Ted Zlatanov
Subject: Re: spam2.el
Date: Mon, 14 Sep 2009 14:29:36 -0500
User-agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1.50 (gnu/linux)

On Thu, 10 Sep 2009 22:55:03 +0300 Teemu Likonen <> 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 :)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]