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

[Simon Josefsson <jas@extundo.com>]

"Ted Zlatanov" <tzz@lifelogs.com> writes:

> On Wed, 21 Sep 2005, bkhl@elektrubadur.se wrote:
>
>> "Ted Zlatanov" <tzz@lifelogs.com> writes:
>> 
>>> If you see this on the second entry on an article that was already in
>>> the group on the first entry, try another experiment: mark an article
>>> with `!' in the summary buffer, then exit.  If the ! mark persists,
>>> then the unread/unseen state is not preserved correctly, and we need
>>> to bug the maintainer of the nnml backend.
>> 
>> That's what happens. Who's that then?
>
> nnml.el says:
>
> ;; Authors: Didier Verna <didier@xemacs.org> (adding compaction)
> ;;      Simon Josefsson <simon@josefsson.org> (adding MARKS)
> ;;      Lars Magne Ingebrigtsen <larsi@gnus.org>
> ;;      Masanobu UMEDA <umerin@flab.flab.fujitsu.junet>
>
> I would guess that Simon would be a great person to contact, since
> this seems marks-related.

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 suspect what is happening is that spam.el set the spam flag without
calling that function, and then the next time you enter the group, the
nnml marks code will revert the flag to what is stored under
~/News/nnml/ because it believes those marks to be more recent.

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.

I didn't actually read any code to answer this, and my memory of all
this may be failing.