Configuring spam.el: A few questions

Configuring spam.el: A few questions

[Jonas Steverud]

Hello. I'm still working on my spam.el config and there are a few
topic I have some difficulties to understand (I don't want to do 'trial
and error' since loosing emails are not an option):

I have a set up of a lot of nnfolders and one is the spam group,
nnfolder:Spam. I want all spam found during splitting to end up in
this group:

At the top topic ('Email') I have the topic property:
((spam-process-destination . "nnfolder:Spam"))

The Spam-group is part of this topic.

I want all spam I detect in the other groups to be marked as spam
(i.e. I will set the spam mark) and then it should be sent to
bogofilter and then deleted.

As I've understood it, all spam marked mails will be moved to the
Spam-group due to the topic parameter above, but then? I enter the
group every now and then. But I don't quite understand how I tell
spam.el to train bogofilter on the content of nnfolder:Spam. What I'm
slightly afraid of is that Gnus ends up in an infinite loop and moves
the content of nnfolder:Spam to the nnfolder:Spam folder.

I assume I have to set spam-move-spam-nonspam-groups-only to t to
prevent this, right?


If I've understood it correctly, if I set the group parameters of
nnfolder:Spam to
     ((spam-contents gnus-group-spam-classification-spam))
everything will work as expected, i.e. bogofilter is trained on the
contents of nnfolder:Spam and the content is not moved anywhere,
right?

I will not use spam-autodetect since I only receive emails (as I said
earlier I do not read USENET any longer) and I use fancy splitting.

What I quite don't follow is how I tell Gnus/spam.el to delete all
spam it has found.

There are two potential scenarios that I would find acceptable:

1. Any found spam is moved to nnfolder:Spam and then trained when I
   enter and exit that group and then deleted.

2. Any found spam during splitting goes to nnfolder:Spam and it is
   treated as above. Any spam I find in any other group which I mark
   as spam (with gnus-summary-mark-as-spam) is then processed by
   bogofilter as spam and then deleted. I.e. never moved to any other group.

Anyone that would like to spread some light?  :-)

Thank you.

/Jonas
-- 
(        http://hem.bredband.net/steverud/        !     Wei Wu Wei     )
(        Meaning of U2 Lyrics, Roleplaying        !  To Do Without Do  )

Re: Configuring spam.el: A few questions

[Ted Zlatanov]

On Wed, 31 Mar 2004, tvrud@bredband.net wrote:

> Hello. I'm still working on my spam.el config and there are a few
> topic I have some difficulties to understand (I don't want to do
> 'trial and error' since loosing emails are not an option):
> 
> I have a set up of a lot of nnfolders and one is the spam group,
> nnfolder:Spam. I want all spam found during splitting to end up in
> this group:
> 
> At the top topic ('Email') I have the topic property:
> ((spam-process-destination . "nnfolder:Spam"))
> 
> The Spam-group is part of this topic.

OK, that's fine.

> I want all spam I detect in the other groups to be marked as spam
> (i.e. I will set the spam mark) and then it should be sent to
> bogofilter and then deleted.

OK.  At the top level, you also want to make bogofilter the spam exit
processor then.

> As I've understood it, all spam marked mails will be moved to the
> Spam-group due to the topic parameter above, but then? 

With a spam exit processor, the spam will also be processed before
it's moved.  Also, it will be marked expired.

> I enter the group every now and then. But I don't quite understand
> how I tell spam.el to train bogofilter on the content of
> nnfolder:Spam. What I'm slightly afraid of is that Gnus ends up in
> an infinite loop and moves the content of nnfolder:Spam to the
> nnfolder:Spam folder.

Since the mail in the Spam folder is marked as expired, you'll be OK.
You can remove the contents of the Spam folder periodically if you
want to.

> I assume I have to set spam-move-spam-nonspam-groups-only to t to
> prevent this, right?

No, this is not necessary, but you can use it if you like.

> If I've understood it correctly, if I set the group parameters of
> nnfolder:Spam to
>      ((spam-contents gnus-group-spam-classification-spam))
> everything will work as expected, i.e. bogofilter is trained on the
> contents of nnfolder:Spam and the content is not moved anywhere,
> right?

What that parameter does is mark all UNSEEN articles in the Spam group
as spam when you enter the Spam group.  So if you have an external
agent that puts articles in Spam, that's one way to quickly catch and
process those articles every time you visit the Spam group.

> There are two potential scenarios that I would find acceptable:
> 
> 1. Any found spam is moved to nnfolder:Spam and then trained when I
>    enter and exit that group and then deleted.
> 
> 2. Any found spam during splitting goes to nnfolder:Spam and it is
>    treated as above. Any spam I find in any other group which I mark
>    as spam (with gnus-summary-mark-as-spam) is then processed by
>    bogofilter as spam and then deleted. I.e. never moved to any
>    other group.

I recommend to use a "Spam" and a "Train" folder since above you're
trying to use the "Spam" folder as both - see my example setup in the
manual and that may give you some ideas.  There is no single way to do
spam filtering, spam.el is very flexible in what it allows.

Both 1 and 2 above are possible with the right spam process
destination and spam exit processor.  Remember that a nil spam process
destination means the spam articles are left in place and marked as
expired - that should make (2) pretty easy.

Ted

Re: Configuring spam.el: A few questions

[Jonas Steverud]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Wed, 31 Mar 2004, tvrud@bredband.net wrote:
[...]
>> As I've understood it, all spam marked mails will be moved to the
>> Spam-group due to the topic parameter above, but then? 
>
> With a spam exit processor, the spam will also be processed before
> it's moved.  Also, it will be marked expired.

I.e. if I set

nnfolder:Spam:
 ((spam-contents gnus-group-spam-classification-spam)
 (ham-marks
  (gnus-ticked-mark)))

 And the Email topic:
 ((spam-process-destination . nil) ;; Necessary at all?
 (spam-process
  (gnus-group-spam-exit-processor-bogofilter)))

And use spam-split in fancy-splitting to nnfolder:Spam I will have the
following setup:

1. Detected spam during splitting will end up in nnfolder:Spam

2. Undetected spam will be split as an ordinary email.

I then start to read my mail and

a. Spam in ordinary groups (e.g. nnfolder:Ding) will be marked with
   M-d and then bogofilter will be trained on it upon exit. The spam
   will be marked expired.

b. Emails in nnfolder:Spam will be considered spam unless I tick 'em.

b1. Ticked emails are moved to ham-process-destination (which I will
    set on topic level to my main mailbox) and bogofilter will be
    trained on it as ham after adding
      (ham-process (gnus-group-ham-exit-processor-bogofilter)) to the
    Email topic parameter.

b2. Spam (i.e. all emails I do not tick) is ... now my understanding
    starts to slip again. It is marked as expired by 
    (spam-contents gnus-group-spam-classification-spam), right? Is
    bogofilter trained on it again? (Doesn't make sense but have to ask.)
    (Will the emails in the Spam group have the $-sign automagically?
    [Have to ask again.])
    

If this is the case, I will "only" need to add the following to .gnus
and then I'm past the finish line, right?

(setq   gnus-registry-cache-file (concat gnus-dribble-directory
					 "gnus.registry.eld")
  
	spam-use-bogofilter t
	spam-use-BBDB t ;; Whitelist
	spam-log-to-registry t
	
	spam-mark-ham-unread-before-move-from-spam-group t
	)

(spam-initialize) 
(gnus-registry-initialize)

I also need to add (: gnus-registry-split-fancy-with-parent) to the
split rules.


I quite don't understand the difference between the
(: gnus-registry-split-fancy-with-parent) and the
(: nnmail-split-fancy-with-parent). Anyone that cares to explain the
difference and/or the idea behind the registry?


>> If I've understood it correctly, if I set the group parameters of
>> nnfolder:Spam to
>>      ((spam-contents gnus-group-spam-classification-spam))
>> everything will work as expected, i.e. bogofilter is trained on the
>> contents of nnfolder:Spam and the content is not moved anywhere,
>> right?
>
> What that parameter does is mark all UNSEEN articles in the Spam group
> as spam when you enter the Spam group.

Unseen = all emails that for one reason or the other is nor shown in
the summary buffer, e.g. read emails. Or is there some other (Gnus
specific) terminology I've missed?

> I recommend to use a "Spam" and a "Train" folder since above you're
> trying to use the "Spam" folder as both

OK. I will try to avoid the Train folder if possible, which according
to my understanding above I can.

Thanks for the help so far! :-)

-- 
(        http://hem.bredband.net/steverud/        !     Wei Wu Wei     )
(        Meaning of U2 Lyrics, Roleplaying        !  To Do Without Do  )

Re: Configuring spam.el: A few questions

[Ted Zlatanov]

On Sat, 03 Apr 2004, tvrud@bredband.net wrote:
> Ted Zlatanov <tzz@lifelogs.com> writes:
> 
>> On Wed, 31 Mar 2004, tvrud@bredband.net wrote:
> [...]
>>> As I've understood it, all spam marked mails will be moved to the
>>> Spam-group due to the topic parameter above, but then? 
>>
>> With a spam exit processor, the spam will also be processed before
>> it's moved.  Also, it will be marked expired.
> 
> I.e. if I set
> 
> nnfolder:Spam:
>  ((spam-contents gnus-group-spam-classification-spam)
>  (ham-marks
>   (gnus-ticked-mark)))
> 
>  And the Email topic:
>  ((spam-process-destination . nil) ;; Necessary at all?

I would keep it, to make sure it is always nil (if
spam-process-destination is set higher in the topic hierarchy it could
override this one).

>  (spam-process
>   (gnus-group-spam-exit-processor-bogofilter)))
> 
> And use spam-split in fancy-splitting to nnfolder:Spam I will have
> the following setup:
> 
> 1. Detected spam during splitting will end up in nnfolder:Spam
> 
> 2. Undetected spam will be split as an ordinary email.
> 
> I then start to read my mail and
> 
> a. Spam in ordinary groups (e.g. nnfolder:Ding) will be marked with
>    M-d and then bogofilter will be trained on it upon exit. The spam
>    will be marked expired.

Yes.

> b. Emails in nnfolder:Spam will be considered spam unless I tick
> 'em.

Yes.

> b1. Ticked emails are moved to ham-process-destination (which I will
>     set on topic level to my main mailbox) and bogofilter will be
>     trained on it as ham after adding
>       (ham-process (gnus-group-ham-exit-processor-bogofilter)) to
>       the
>     Email topic parameter.

Exactly.

> b2. Spam (i.e. all emails I do not tick) is ... now my understanding
>     starts to slip again. It is marked as expired by (spam-contents
>     gnus-group-spam-classification-spam), right? Is bogofilter
>     trained on it again? (Doesn't make sense but have to ask.)
>     (Will the emails in the Spam group have the $-sign
>     automagically?  [Have to ask again.])

All the spam is processed by the spam processor, marked expired, and
sent to the spam destination, regardless of the group classification.
So the result is the same as if you had processed the spam in any
other group with those parameters.  This is only the case for spam;
ham has different processing rules depending on the group
classification.

> If this is the case, I will "only" need to add the following to
> .gnus and then I'm past the finish line, right?
> 
> (setq   gnus-registry-cache-file (concat gnus-dribble-directory
> 					 "gnus.registry.eld")
>   
> 	spam-use-bogofilter t
> 	spam-use-BBDB t ;; Whitelist
> 	spam-log-to-registry t
> 	
> 	spam-mark-ham-unread-before-move-from-spam-group t
> 	)
> 
> (spam-initialize) 
> (gnus-registry-initialize)
> 
> I also need to add (: gnus-registry-split-fancy-with-parent) to the
> split rules.

I think that's it.

> I quite don't understand the difference between the
> (: gnus-registry-split-fancy-with-parent) and the
> (: nnmail-split-fancy-with-parent). Anyone that cares to explain the
> difference and/or the idea behind the registry?

The registry is a way to keep track of articles by message ID, and to
record in what groups that message ID has been seen.  Tracking parent
articles is done with the References header, which indicates the
message IDs of parent articles.  Article copies, moves, and deletions
are tracked.

The nnmail-split-fancy-with-parent method was the inspiration, and
it's quite similar, but it's more limited because it only works for
nnmail.

> Unseen = all emails that for one reason or the other is nor shown in
> the summary buffer, e.g. read emails. Or is there some other (Gnus
> specific) terminology I've missed?

"Unseen" are those articles you never saw before.

"Unread" are those that are not marked read, expired, ticked, etc.

I know this can be confusing...

Hope that helps.

Ted

Re: Configuring spam.el: A few questions

[Jonas Steverud]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Sat, 03 Apr 2004, tvrud@bredband.net wrote:
[...]
>> I quite don't understand the difference between the
>> (: gnus-registry-split-fancy-with-parent) and the
>> (: nnmail-split-fancy-with-parent). Anyone that cares to explain the
>> difference and/or the idea behind the registry?
>
> The registry is a way to keep track of articles by message ID, and to
> record in what groups that message ID has been seen.  Tracking parent
> articles is done with the References header, which indicates the
> message IDs of parent articles.  Article copies, moves, and deletions
> are tracked.
>
> The nnmail-split-fancy-with-parent method was the inspiration, and
> it's quite similar, but it's more limited because it only works for
> nnmail.

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 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.

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.

> "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.

Thank you very much for your help! I will implement this in a matter
of hours, I think. :-D

-- 
(        http://hem.bredband.net/steverud/        !     Wei Wu Wei     )
(        Meaning of U2 Lyrics, Roleplaying        !  To Do Without Do  )

Re: Configuring spam.el: A few questions

[Ted Zlatanov]

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

Re: Configuring spam.el: A few questions

[Kai Grossjohann]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Fri, 16 Apr 2004, tvrud@bredband.net wrote:
>
>> 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.

I (almost) never copy messages, so I only thought about moving, not
copying.  And then, I'm lazy...

I think that these days, people should use the gnus-registry.  It's
better in all ways that I can think of.

Does this help?

Kai

Re: Configuring spam.el: A few questions

[Jonas Steverud]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Fri, 16 Apr 2004, tvrud@bredband.net wrote:
[...]
>>> "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.

Currently the info node Terminology is not sorted, the order in ngnus
0.01 the order is news, mail, reply, follow up, back end, ... Since
the list is starting to getting long I don't think they should occur,
IMHO, in "logical" order - e.g. related items are groups together -
but in sorted order, i.e. back end, follow up, mail, news, reply.

I think one should more or less add the texts you gave above for
unseen and unread.

Since Gnus can mark an article in so very many different ways and it
is not obvious for a newbie to understand that the X mark makes the
article unseen, read and ancient (to take a couple of classifications
out of the blue). Therefore I think it is important to explain the
terminology everyone else takes for granted. All IMHO off course.

(The reason I do not add this myself is that a do not have write
access to the CVS and that I haven't signed any papers. I could write
down the text and email someone whom could commit it, but since I
technically is owning the copyright [lets not get into that legal
argument, shall we? I think you all understand what I mean] then and
FSF is a bit finicky about that nowadays, I prefer not to do it. But
if someone convinces me that it is all right I will probably do so,
i.e. send the list some edited texts [or anyone that volunteers for
committing? ;-) ].)

-- 
(        http://hem.bredband.net/steverud/        !     Wei Wu Wei     )
(        Meaning of U2 Lyrics, Roleplaying        !  To Do Without Do  )

Re: Configuring spam.el: A few questions

[Dan Christensen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> "Unseen" are those articles you never saw before.

If someone decides to add an entry to the terminology section, I think
this should be clarified to something like:

  "Unseen"

  An article is unseen if it is appearing in the summary buffer
  for the first time.  

(Whether or not you "saw" the article *body* is not relevant.
This is the distinction between unseen and unread.)

> "Unread" are those that are not marked read, expired, ticked, etc.

Hmm, isn't an expired article considered "read"?

Dan

Re: Configuring spam.el: A few questions

[Kai Grossjohann]

Dan Christensen <jdc@uwo.ca> writes:

> Ted Zlatanov <tzz@lifelogs.com> writes:
>
>> "Unread" are those that are not marked read, expired, ticked, etc.
>
> Hmm, isn't an expired article considered "read"?

It is quite confusing that "read" is used as a category (read versus
unread) but also as a specific mark that is part of the "read"
category.

Kai

Re: Configuring spam.el: A few questions

[Dan Christensen]

Kai Grossjohann <kai@emptydomain.de> writes:

> Dan Christensen <jdc@uwo.ca> writes:
>
>> Ted Zlatanov <tzz@lifelogs.com> writes:
>>
>>> "Unread" are those that are not marked read, expired, ticked, etc.
>>
>> Hmm, isn't an expired article considered "read"?
>
> It is quite confusing that "read" is used as a category (read versus
> unread) but also as a specific mark that is part of the "read"
> category.

Yes, it is confusing, and I was confused.  In fact, I meant to say
"isn't a ticked article considered unread?"  I saw expired and ticked
grouped together and thought that one of them must be wrong, but I
think it is ticked that is wrong.  Right? ... Fumbles through the info
pages...  Hmm, from the node called (not surprisingly) "Unread
Articles", we have

|    The following marks mark articles as (kinda) unread, in one form or
| other.
| 
| `!'
|      Marked as ticked (`gnus-ticked-mark').
| 
...
| 
| `?'
|      Marked as dormant (`gnus-dormant-mark').
| 
...
| 
| `SPACE'
|      Marked as unread (`gnus-unread-mark').
| 
|      "Unread articles" are articles that haven't been read at all yet.

The last two lines seem to contradict the first line, so maybe there
is no strict definition of what "unread" means.

Dan

Terminology (was: Configuring spam.el: A few questions)

[Jonas Steverud]

Dan Christensen <jdc@uwo.ca> writes:

[...]
> The last two lines seem to contradict the first line, so maybe there
> is no strict definition of what "unread" means.

Seems like it is time IMHO for some spring cleaning...?

It seems like the big problem is the terms "read" and "unread" that is
the problem.

Suggested new terms/definitions:
 Visited: A article that the user has seen before; read, ticked,
          dormant, marked as expireable, ... (Other criteria?)

 Read: An article that has been marked as killed, ancient, read in the
       naïve sense; i.e. actually *read*, ... I.e. not ticked etc.

 Unvisted or Unread: Replaces Unseen which I find confusing - an
                     article that is killed and yanked from the
                     summary buffer is in my view unseen.

 Unseen: (?) Articles that are unvisited but not shown in the summary
         buffer, usually expunged articles due to scoring.

Maybe Unseen should be considered Visited, i.e. an expunged article is
considered visited. But isn't it a difference between expunge and
mark-and-expunge? (Checks info...) Yes it is. (Actually, what happens
with an article that is expunged but not marked as read? Will it still
count as unread and the group will show unread articles in *Group* buffer?)

I have not given this very much thought but the unread/read and unseen
terms seams a little confusing and maybe it should be replaced by
"visited" or some similar term? Opinions?

-- 
(        http://hem.bredband.net/steverud/        !     Wei Wu Wei     )
(        Meaning of U2 Lyrics, Roleplaying        !  To Do Without Do  )

Re: Terminology

[Simon Josefsson]

Jonas Steverud <tvrud@bredband.net> writes:

> Dan Christensen <jdc@uwo.ca> writes:
>
> [...]
>> The last two lines seem to contradict the first line, so maybe there
>> is no strict definition of what "unread" means.
>
> Seems like it is time IMHO for some spring cleaning...?
>
> It seems like the big problem is the terms "read" and "unread" that is
> the problem.
>
> Suggested new terms/definitions:
>  Visited: A article that the user has seen before; read, ticked,
>           dormant, marked as expireable, ... (Other criteria?)

I'm not sure we need to introduce more terms...  (But we could keep
the term "visited" around for when we need a new class of read marks.)

>  Read: An article that has been marked as killed, ancient, read in the
>        naïve sense; i.e. actually *read*, ... I.e. not ticked etc.

There is a Gnus mark called "read".  If you tick an active article, it
will become read automatically.  Same for if you mark an article as
expired, etc.

>  Unvisted or Unread: Replaces Unseen which I find confusing - an
>                      article that is killed and yanked from the
>                      summary buffer is in my view unseen.

"Unread" is not a proper Gnus mark.  It might help understanding if
you think of "unread" as an implicit mark, i.e. one that holds if
nothing else holds.  So an article can't be marked both expired and
unread, as unread isn't a mark.  "unread" is just an absence of marks.
Of course, the exception to that rule is the "unseen" mark.

>  Unseen: (?) Articles that are unvisited but not shown in the summary
>          buffer, usually expunged articles due to scoring.

"unseen" is another Gnus mark, it is maintained by Gnus internally and
you can't set/clear it.  Its purpose is to let you know which messages
you have never seen before.  This is not the same as "unread", as you
can M-u an article to make it "unread" (but not "unseen").  "Unread"
articles may be "seen", but "unseen" articles cannot be "read".

IIRC, that is.

Re: Terminology

[Jonas Steverud]

Simon Josefsson <jas@extundo.com> writes:

> Jonas Steverud <tvrud@bredband.net> writes:
[...]
>> Suggested new terms/definitions:
>>  Visited: A article that the user has seen before; read, ticked,
>>           dormant, marked as expireable, ... (Other criteria?)
>
> I'm not sure we need to introduce more terms...  (But we could keep
> the term "visited" around for when we need a new class of read marks.)

The main idea was not to introduce new terms but rename old, confusing ones.

The name "visited" I got from the Emacs terminology of visited
files. A consistent terminology that I personally like. 

>>  Read: An article that has been marked as killed, ancient, read in the
>>        naïve sense; i.e. actually *read*, ... I.e. not ticked etc.
>
> There is a Gnus mark called "read".  If you tick an active article, it
> will become read automatically.  Same for if you mark an article as
> expired, etc.

OK, I didn't know ticked articles counted as read. Doesn't matter
much, remove "I.e. not ticked etc." from my text above. :-)

>>  Unvisted or Unread: Replaces Unseen which I find confusing - an
>>                      article that is killed and yanked from the
>>                      summary buffer is in my view unseen.
>
> "Unread" is not a proper Gnus mark.  It might help understanding if
> you think of "unread" as an implicit mark, i.e. one that holds if
> nothing else holds.  So an article can't be marked both expired and
> unread, as unread isn't a mark.  "unread" is just an absence of marks.
> Of course, the exception to that rule is the "unseen" mark.

I didn't talk of specific marks that Gnus keeps track of, I was more
concerned about the terminology - classifications of articles.

Previous mails has indicated that there are some confusion regarding
what we call an article - sometimes regardless of the actual marks of
it and sometimes the marks are considered - and I just tries to see if
we can do something about that confusion. Renaming some of the terms
might help.

>>  Unseen: (?) Articles that are unvisited but not shown in the summary
>>          buffer, usually expunged articles due to scoring.
>
> "unseen" is another Gnus mark,

I didn't know that. Makes things a little more complicated then.

-- 
(        http://hem.bredband.net/steverud/        !     Wei Wu Wei     )
(        Meaning of U2 Lyrics, Roleplaying        !  To Do Without Do  )

Re: Configuring spam.el: A few questions

[Kai Grossjohann]

Dan Christensen <jdc@uwo.ca> writes:

> The last two lines seem to contradict the first line, so maybe there
> is no strict definition of what "unread" means.

The term is strictly ambiguous ;-)

Kai

Re: Terminology

[Simon Josefsson]

Jonas Steverud <tvrud@bredband.net> writes:

> Previous mails has indicated that there are some confusion regarding
> what we call an article - sometimes regardless of the actual marks of
> it and sometimes the marks are considered - and I just tries to see if
> we can do something about that confusion. Renaming some of the terms
> might help.

Or perhaps just document the current terms some more...

Perhaps what the manual need are short, self-contained, sections
focused on particular topic.  I have been thinking about writing a
"Non-ASCII survival guide" node with all variables (Gnus + Message,
sending and receiving, etc) a few times, but couldn't figure out how
to write it in a style that would blend in.  "Non-ASCII" is perhaps a
too large topic, but a "Marks & Flags survival guide" section might be
more appropriate.

Re: Terminology

[Kai Grossjohann]

Simon Josefsson <jas@extundo.com> writes:

> Jonas Steverud <tvrud@bredband.net> writes:
>
>> Previous mails has indicated that there are some confusion regarding
>> what we call an article - sometimes regardless of the actual marks of
>> it and sometimes the marks are considered - and I just tries to see if
>> we can do something about that confusion. Renaming some of the terms
>> might help.
>
> Or perhaps just document the current terms some more...

I'm not sure that we want to document "`read' is ambiguous".  I guess
that it would be much better to avoid ambiguity.

WDYT?

Kai

PS: *The* `read' mark is shown as the characters R and r, whereas *a*
    `read' mark could be any of R, r, K, Y, ...

Re: Terminology

[Ted Zlatanov]

On Mon, 19 Apr 2004, kai@emptydomain.de wrote:

> I'm not sure that we want to document "`read' is ambiguous".  I
> guess that it would be much better to avoid ambiguity.

It's obvious some sort of clarification would be useful.

Let's not confuse the terminology of marks with the terminology of
articles - e.g. there's no "unread" mark but there are unread
articles.  Maybe the two terminologies should be clearly separated but
in the same section.

Additionally, it may be confusing to non-native English speakers that
the word "read" is both the present tense and past tense of the verb
"to read," in addition to being an adjective.  Unfortunately English
is full of these ambiguities.

Ted