Re: Configuring spam.el: A few questions

[Ted Zlatanov <tzz@lifelogs.com>]

On Fri, 16 Apr 2004, tvrud@bredband.net wrote:
> I see. One reason for my confusion where the line "This is the
> gnus-registry.el package, works with other backends besides
> nnmail.", which I interpret as "the registry does not work with
> nnmail." I later realises what the "besides" nnmail means in this
> context. My fault, sorry.

I'll fix that in the comments for the next CVS commit.

> I found a ... bug or flaw, depending on how you see it, in
> nnmail-split-fancy-with-parent. If I copy one of you emails to
> another group, e.g. nnfolder:ToDo, responses end up in the ToDo
> group instead of in the Ding group. In one sense, this is correct
> behavior but how do I make it not happen for copied mails? Not that
> it is a big issue, I'm just curious.

For nnmail-split-fancy-with-parent, you should ask the people that
maintain that code, it's not me.  With copies there's no 100% correct
behavior, there's a clear case to be made that the newer copy should
get priority as well.  gnus-registry returns the first group it finds,
which is no more correct than any other approach IMO.  We could have a
list of regexes that match "preferred groups" though if that seems
better.

> If I've understood it correctly, nnmail is the mail handling
> interface, the front end "Gnus" sees and then it uses a number of
> backends like nnfolder to actually store and handle the
> emails. Right?  I.e. nnmail is not a backend that can replace
> nnfolder et all.

Think in OOP terms - nnmail is like a parent object that has common
functionality for many backends, but by itself it's not a full
implementation.

>> "Unseen" are those articles you never saw before.
>>
>> "Unread" are those that are not marked read, expired, ticked, etc.
> 
> This could be added to the Terminology node in the info file (which
> I just found) (and which could do with some M-x sort-lines ;-)
> ). IMHO.

If you submit a patch to show what you mean, that would be very
helpful.

Thanks
Ted