spam2.el (was: How to unregister message as spam/ham?)

spam2.el (was: How to unregister message as spam/ham?)

[Ted Zlatanov]

The following message is a courtesy copy of an article
that has been posted to gnu.emacs.gnus as well.

On Wed, 09 Sep 2009 23:24:04 +0200 asjo@koldfront.dk (Adam Sjøgren) wrote: 

AS> On Wed, 09 Sep 2009 16:15:32 -0500, Ted wrote:
>> I think your solution is fine.  It's been a while since I looked at the
>> code, but I probably made a mistake with the duplicate elimination.

AS> Great! Or, well, you understand what I mean, I trust.

AS> (The patch does work for me, though - so in the specific case is isn't
AS> necessarily defective as such.)

>> I'm OK with you comitting it.  I personally use a server-based solution
>> so I haven't needed this functionality in years.

AS> I haven't got a commit bit, so if someone who has would like to, please
AS> feel free. (I have signed papers.)

Can you prepare a full patch, with a ChangeLog entry?

>> I think spam.el has been around long enough that we should consider
>> redesigning it with what we've learned from the users' experience and
>> feedback.  For instance, setting it up is much too complicated for 99%
>> of the users, while mentats like it just fine.

AS> I don't know what mentats are, but I agree. I wrote down a recipe way
AS> back when, and have used that since.

Mentats are in the Dune books by Frank Herbert.  Basically human
computers.  http://en.wikipedia.org/wiki/Mentat

Anyone using spam.el:

What parts of spam.el do you like?  How do you use it?

What parts are too complicated?

What does it not do today but should?

I'll start:

- I like the automatic message moving (ham out of spam groups and spam
  out of non-spam groups).  I use that in conjunction with server-based
  CRM114 filtering completely outside Gnus.

- the backend setup in the spam.el code is complicated.  The
  server/topic spam-related parameters are too numerous and probably
  should be outside it.

- first-time setup is unpleasantly complex

- today it does not interact with GMail's built-in spam folders.
  There's been recipes for that, but it probably should just work with a
  simple setup statement (spam-backend-gmail?).

Ted

Re: spam2.el

[Ted Zlatanov]

The following message is a courtesy copy of an article
that has been posted to gnu.emacs.gnus as well.

On Thu, 10 Sep 2009 22:55:03 +0300 Teemu Likonen <tlikonen@iki.fi> 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