Re: What's wrong with my spam.el settings now?

["Ted Zlatanov" <tzz@lifelogs.com>]

On Wed, 21 Sep 2005, jas@extundo.com wrote:

> How is spam.el setting the spam mark?  In particular, is it using the
> gnus-request-set-mark interface?  That interface must be called with
> the flag update whenever any code that alter message flags without
> going through the summary buffer variables (which are turned into
> gnus-request-set-mark calls when exiting the group).

I do it with gnus-summary-mark-article:

5 matches for "mark-article" in buffer: spam.el
   1325:	    (gnus-summary-mark-article article gnus-spam-mark))
   1387:      (gnus-summary-mark-article article gnus-expirable-mark)))
   1427:	    (gnus-summary-mark-article article gnus-unread-mark))
   1432:	    (gnus-summary-mark-article article gnus-expirable-mark))
   1708:		 (gnus-summary-mark-article article gnus-spam-mark))

which worked fine so far.

If that's wrong, what's the right way to do it (if you can point me to
code that does the right thing, I'll make sure to implement mine the
same way)?

> If the spam mark should never be synced across Gnus installations,
> then it should be added to gnus-article-unpropagated-mark-lists, then
> the nnml code will not revert the spam flag.  However, it seems like
> the spam mark should be synchronized between Gnus installations,
> should it not?  Then the spam.el code has to call the g-r-s-m
> interface when updating the marks.

The spam mark is ephemeral, it only matters for the duration of a
summary visit.  When you exit, spam-marked articles get processed and
expired.  I did this intentionally when I started writing the spam.el
logic.

Ted