Re: [Pan-users] Scoring

[Duncan]

Theodore M Rolle Jr posted on Sun, 20 Oct 2013 19:50:27 -0400 as
excerpted:

> Duncan,
> 
> Lacrocivious sent me here from the IRC channel, recommending you as one
> who "knows the rules."
> 
> I need to get a better understanding of the Score file rules.
> I know there's more efficient rules than Pan creates.
> 
> Ted

Definitely so.

Pan uses the same basic scorefile format and rules as slrn, altho some of 
slrn's advanced scorefile features such as includes aren't implemented.  
An exception is that pan's regex are case insensitive.

Unfortunately the slrn.org domain appears to have expired and is now 
"parked", so the scoring.txt file bookmark I've used for years is no 
longer valid.  Googling...

Found it at sourceforge! Updating bookmark! =:^)

http://slrn.sourceforge.net/docs/score.txt

The MS-based news client xnews has a similar but not identical scorefile 
format as well, the biggest difference there being that it uses regex for 
the group names too, instead of the wildcard format slrn uses for them.  
So the xnews scoring doc can be read as well for a different viewpoint, 
tho if you think it'll only mix you up, of course don't.

http://xnews.remarqs.net/scoring.txt

In terms of efficiency and neatness, there's several points to remember:

* Comments begin with a % character, and pan adds a *LOT* of comments.  
All those %BOS/%EOS lines, etc, are pan comments that at least I find to 
be more noise than signal, so I delete them.  The only pan comments I 
actually keep are the date lines for expiring scores, as I find it useful 
to know when I created an expiring score as well as when it expires.  All 
the others, gone.

I do have a few of my own comments as notes at the beginning of my 
scorefile (including links to the two scorefile docs as well as some very 
brief format notes), and of course use separator lines of %#### or %%%%%% 
where I find them useful, but I do **NOT** have more comment lines than 
actual operational lines, as pan tends to do on its own.


* If you look at pan's event log from when pan starts, you'll see where 
it reads the scorefile, and it'll tell you how many scores in how many 
sections you have, along with how many expired scores it loaded and then 
immediately expired (note that it doesn't remove expired scores from the 
scorefile, it simply removes them from memory after loading them and 
finding they're expired.  So obviously, weed out all the expired ones 
from time to time (tho I prefer to keep at least one expiring score 
around for example purposes, even if it's expired, so I never remove the 
last one).

* The newsgroup lines with their [] enclosures serve as section 
delimiters.  These are the sections pan refers to in its log, so if you 
can, generalize your newsgroup names and group as many scores under each 
newsgroup as possible, thus reducing the number of "sections" pan has to 
process and keep in memory.

* Similarly, the score keyword lines delimit actual tests/scores, so 
where possible, group as many conditions ORed together under the same 
score lines.


Using this strategy, the pan event log says I have only eight scoring 
rules in three sections, altho I guess I have several hundred individual 
conditions.


* Meanwhile, it's worth noting that as with slrn, pan should now be able 
to score on all headers (IIRC Heinrich added that feature a year or two 
ago, so it's not "new", but if you're running an older distro version or 
something, say 0.136 or earlier altho I'm not sure that's the specific 
one, it might not work for you), not just the ones available in the pan 
scoring GUI, altho the ones in the GUI tend to be the headers available 
in the overview file and thus are VASTLY more efficient to process.  Non-
overview headers cannot be scored until pan actually downloads the full 
headers, which usually means the full message, since that's when it 
actually has them available to score on.  While that's still better than 
nothing if it prevents you from having to process the message manually, 
the message must still be downloaded and that's obviously not as 
efficient as being able to score on the overview file headers, since the 
overview files is what pan actually gets when it "gets headers", so it 
can process those scores then, and avoid the actual download entirely for 
ignored scores and the like.

Of course with the automated actions feature, it's now possible to have 
pan mark-read or delete ignored (or negative-scored) messages, and being 
able to do so based on scores from headers in the overviews means you 
don't have to worry about seeing or downloading those messages at all.  
Again, scoring on other headers can still be useful if it means you don't 
have to look at it, but you don't avoid the download that way.

Of course the other side of that is that you can set (for example) 
watched messages to auto-cache or auto-download... again, *IF* you can 
score on headers found in the overview, thus before you've manually 
downloaded it anyway.

I'll post a followup with parts of my scorefile, so you can see and 
perhaps copy the format-note comments I have, as well as see the format 
organization I'm using.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman