Other people use kill files, but we here at Gnus Towers like scoring better than killing, so we'd rather switch than fight. They do something completely different as well, so sit up straight and pay attention!
All articles have a default score (gnus-summary-default-score
),
which is 0 by default. This score may be raised or lowered either
interactively or by score files. Articles that have a score lower than
gnus-summary-mark-below
are marked as read.
Gnus will read any score files that apply to the current group before generating the summary buffer.
There are several commands in the summary buffer that insert score entries based on the current article. You can, for instance, ask Gnus to lower or increase the score of all articles with a certain subject.
There are two sorts of scoring entries: Permanent and temporary. Temporary score entries are self-expiring entries. Any entries that are temporary and have not been used for, say, a week, will be removed silently to help keep the sizes of the score files down.
The score commands that alter score entries do not actually modify real score files. That would be too inefficient. Gnus maintains a cache of previously loaded score files, one of which is considered the current score file alist. The score commands simply insert entries into this list, and upon group exit, this list is saved.
The current score file is by default the group's local score file, even if no such score file actually exists. To insert score commands into some other score file (eg. `all.SCORE'), you must first make this score file the current one.
General score commands that don't actually change the score file:
gnus-summary-set-score
).
gnus-summary-current-score
).
gnus-score-find-trace
).
gnus-summary-rescore
). This might be useful if you're playing
around with your score files behind Gnus' back and want to see the
effect you're having.
gnus-summary-score-entry
).
gnus-score-change-score-file
).
gnus-score-edit-current-scores
).
You will be popped into a gnus-score-mode
buffer (see section Score File Editing).
gnus-score-edit-file
).
gnus-score-flush-cache
). This is useful
after editing score files.
gnus-score-customize
).
gnus-summary-raise-score
).
gnus-summary-lower-score
).
The rest of these commands modify the local score file.
gnus-score-set-mark-below
).
gnus-score-set-expunge-below
).
The keystrokes for actually making score entries follow a very regular pattern, so there's no need to list all the commands. (Hundreds of them.)
strings
date
number
So, let's say you want to increase the score on the current author with exact matching permanently: I a e p. If you want to lower the score based on the subject line, using substring matching, and make a temporary score entry: L s s t. Pretty easy.
To make things a bit more complicated, there are shortcuts. If you use a capital letter on either the second or third keys, Gnus will use defaults for the remaining one or two keystrokes. The defaults are "substring" and "temporary". So I A is the same as I a s t, and I a R is the same as I a r t.
The gnus-score-mimic-keymap
says whether these commands will
pretend they are keymaps or not.
There aren't many of these as yet, I'm afraid.
gnus-score-flush-cache
).
gnus-use-scoring
nil
, Gnus will not check for score files, and will not, in
general, do any score-related work. This is t
by default.
gnus-kill-killed
nil
, Gnus will never apply score files to
articles that have already been through the kill process. While this
may save you lots of time, it also means that if you apply a kill file
to a group, and then change the kill file and want to run it over you
group again to kill more articles, it won't work. You have to set this
variable to t
to do that. (It is t
by default.)
gnus-kill-files-directory
SAVEDIR
environment variable by default.
This is `~/News/' by default.
gnus-score-file-suffix
gnus-score-uncacheable-files
gnus-save-score
t
. This will make
Gnus save the scores into the `.newsrc.eld' file.
gnus-score-interactive-default-score
gnus-summary-default-score
gnus-score-over-mark
gnus-score-below-mark
gnus-score-find-score-files-function
gnus-score-find-single
gnus-score-find-bnews
gnus-score-find-hierarchical
gnus-score-expiry-days
nil
, no score file entries
are expired. It's 7 by default.
gnus-update-score-entry-dates
nil
, matching score entries will have
their dates updated. (This is how Gnus controls expiry--all
non-matching entries will become too old while matching entries will
stay fresh and young.) However, if you set this variable to nil
,
even matching entries will grow old and will have to face that oh-so
grim reaper.
gnus-score-after-write-file-function
A score file is an emacs-lisp
file that normally contains just a
single form. Casual users are not expected to edit these files;
everything can be changed from the summary buffer.
Anyway, if you'd like to dig into it yourself, here's an example:
(("from" ("Lars Ingebrigtsen" -10000) ("Per Abrahamsen") ("larsi\\|lmi" -50000 nil R)) ("subject" ("Ding is Badd" nil 728373)) ("xref" ("alt.politics" -1000 728372 s)) ("lines" (2 -100 nil <)) (mark 0) (expunge -1000) (mark-and-expunge -10) (read-only nil) (orphan -10) (adapt t) (files "/hom/larsi/News/gnu.SCORE") (exclude-files "all.SCORE") (local (gnus-newsgroup-auto-expire t) (gnus-summary-make-false-root 'empty)) (eval (ding)))
This example demonstrates absolutely everything about a score file.
Even though this looks much like lisp code, nothing here is actually
eval
ed. The lisp reader is used to read this form, though, so it
has to be legal syntactically, if not semantically.
Six keys are supported by this alist:
STRING
From
, Subject
, References
, Message-ID
,
Xref
, Lines
, Chars
and Date
. In addition to
these headers, there are three strings to tell Gnus to fetch the entire
article and do the match on larger parts of the article: Body
will perform the match on the body of the article, Head
will
perform the match on the head of the article, and All
will
perform the match on the entire article. Note that using any of these
last three keys will slow down group entry considerably. The
final "header" you can score on is Followup
. These score
entries will result in new score entries being added for all follow-ups
to articles that matches these score entries.
Following this key is a arbitrary number of score entries, where each
score entry has one to four elements.
gnus-score-interactive-default-score
number will be used
instead. This is 1000 by default.
r
and R
(regexp) as
well as s
and S
(substring) types and e
and
E
(exact match) types. If this element is not present, Gnus will
assume that substring matching should be used. R
and S
differ from the other two in that the matches will be done in a
case-sensitive manner. All these one-letter types are really just
abbreviations for the regexp
, string
and exact
types, which you can use instead, if you feel like.
<
, >
,
=
, >=
and <=
.
before
, at
and after
. I can't really imagine this ever being useful, but,
like, it would feel kinda silly not to provide this function. Just in
case. You never know. Better safe than sorry. Once burnt, twice shy.
Don't judge a book by its cover. Never not have sex on a first date.
From
(etc)
header uses.
From
header uses.
References
header
uses.
mark
expunge
mark-and-expunge
thread-mark-and-expunge
gnus-thread-score-function
says how to compute the total score for a thread.
files
exclude-files
eval
eval
el. This element will be
ignored when handling global score files.
read-only
orphan
(orphan -500) (mark-and-expunge -100)When you enter the group the first time, you will only see the new threads. You then raise the score of the threads that you find interesting (with I T or I S), and ignore (C y) the rest. Next time you enter the group, you will see new articles in the interesting threads, plus any new threads. I.e. -- the orphan score atom is for high-volume groups where there exist a few interesting threads which can't be found automatically by ordinary scoring rules.
adapt
t
, the
default adaptive scoring rules will be used. If it is ignore
, no
adaptive scoring will be performed on this group. If it is a list, this
list will be used as the adaptive scoring rules. If it isn't present,
or is something other than t
or ignore
, the default
adaptive scoring rules will be used. If you want to use adaptive
scoring on most groups, you'd set gnus-use-adaptive-scoring
to
t
, and insert an (adapt ignore)
in the groups where you do
not want adaptive scoring. If you only want adaptive scoring in a few
groups, you'd set gnus-use-adaptive-scoring
to nil
, and
insert (adapt t)
in the score files of the groups where you want
it.
adapt-file
local
(VAR VALUE)
pairs.
Each var will be made buffer-local to the current summary buffer,
and set to the value specified. This is a convenient, if somewhat
strange, way of setting variables in some groups if you don't like hooks
much.
You normally enter all scoring commands from the summary buffer, but you might feel the urge to edit them by hand as well, so we've supplied you with a mode for that.
It's simply a slightly customized emacs-lisp
mode, with these
additional commands:
gnus-score-edit-done
).
gnus-score-edit-insert-date
). This is really the day number, if
you were wondering.
gnus-score-pretty-print
) does that for
you.
Type M-x gnus-score-mode to use this mode.
gnus-score-menu-hook
is run in score mode buffers.
In the summary buffer you can use commands like V f and V e to begin editing score files.
If all this scoring is getting you down, Gnus has a way of making it all happen automatically--as if by magic. Or rather, as if by artificial stupidity, to be precise.
When you read an article, or mark an article as read, or kill an
article, you leave marks behind. On exit from the group, Gnus can sniff
these marks and add score elements depending on what marks it finds.
You turn on this ability by setting gnus-use-adaptive-scoring
to
t
.
To give you complete control over the scoring process, you can customize
the gnus-default-adaptive-score-alist
variable. For instance, it
might look something like this:
(defvar gnus-default-adaptive-score-alist '((gnus-unread-mark) (gnus-ticked-mark (from 4)) (gnus-dormant-mark (from 5)) (gnus-del-mark (from -4) (subject -1)) (gnus-read-mark (from 4) (subject 2)) (gnus-expirable-mark (from -1) (subject -1)) (gnus-killed-mark (from -1) (subject -3)) (gnus-kill-file-mark) (gnus-ancient-mark) (gnus-low-score-mark) (gnus-catchup-mark (from -1) (subject -1))))
As you see, each element in this alist has a mark as a key (either a
variable name or a "real" mark--a character). Following this key is
a arbitrary number of header/score pairs. If there are no header/score
pairs following the key, no adaptive scoring will be done on articles
that have that key as the article mark. For instance, articles with
gnus-unread-mark
in the example above will not get adaptive score
entries.
Each article can have only one mark, so just a single of these rules will be applied to each article.
To take gnus-del-mark
as an example--this alist says that all
articles that have that mark (i.e., are marked with `D') will have a
score entry added to lower based on the From
header by -4, and
lowered by Subject
by -1. Change this to fit your prejudices.
If you have marked 10 articles with the same subject with
gnus-del-mark
, the rule for that mark will be applied ten times.
That means that that subject will get a score of ten times -1, which
should be, unless I'm much mistaken, -10.
The headers you can score on are from
, subject
,
message-id
, references
, xref
, lines
,
chars
and date
. In addition, you can score on
followup
, which will create an adaptive score entry that matches
on the References
header using the Message-ID
of the
current article, thereby matching the following thread.
You can also score on thread
, which will try to score all
articles that appear in a thread. thread
matches uses a
Message-ID
to match on the References
header of the
article. If the match is made, the Message-ID
of the article is
added to the thread
rule. (Think about it. I'd recommend two
aspirins afterwards.)
If you use this scheme, you should set the score file atom mark
to something small--like -300, perhaps, to avoid having small random
changes result in articles getting marked as read.
After using adaptive scoring for a week or so, Gnus should start to become properly trained and enhance the authors you like best, and kill the authors you like least, without you having to say so explicitly.
You can control what groups the adaptive scoring is to be performed on by using the score files (see section Score File Format). This will also let you use different rules in different groups.
The adaptive score entries will be put into a file where the name is the
group name with gnus-adaptive-file-suffix
appended. The default
is `ADAPT'.
When doing adaptive scoring, substring or fuzzy matching would probably
give you the best results in most cases. However, if the header one
matches is short, the possibility for false positives is great, so if
the length of the match is less than
gnus-score-exact-adapt-limit
, exact matching will be used. If
this variable is nil
, exact matching will always be used to avoid
this problem.
Gnus offers two commands for picking out the Message-ID
header in
the current buffer. Gnus will then add a score rule that scores using
this Message-ID
on the References
header of other
articles. This will, in effect, increase the score of all articles that
respond to the article in the current buffer. Quite useful if you want
to easily note when people answer what you've said.
gnus-score-followup-article
gnus-score-followup-thread
These two functions are both primarily meant to be used in hooks like
gnus-inews-article-hook
.
Xref
header.
("xref" (" talk.politics.misc:" -1000))
("xref" ("[^:\n]+:[0-9]+ +[^:\n]+:[0-9]+ +[^:\n]+:[0-9]+" -1000 nil r))
Head
, Body
and All
), you should choose one
and stick with it in each score file. If you use any two, each article
will be fetched twice. If you want to match a bit on the
Head
and a bit on the Body
, just use All
for all
the matches.
((mark -100))You may also consider doing something similar with
expunge
.
[^abcd]*
, you may get unexpected results.
That will match newlines, which might lead to, well, The Unknown. Say
[^abcd\n]*
instead.
If you want to keep just articles that have `Sex with Emacs' in the subject header, and expunge all other articles, you could put something like this in your score file:
(("subject" ("Sex with Emacs" 2)) (mark 1) (expunge 1))
So, you raise all articles that match `Sex with Emacs' and mark the rest as read, and expunge them to boot.
Sure, other newsreaders have "global kill files". These are usually nothing more than a single kill file that applies to all groups, stored in the user's home directory. Bah! Puny, weak newsreaders!
What I'm talking about here are Global Score Files. Score files from all over the world, from users everywhere, uniting all nations in one big, happy score file union! Ange-score! New and untested!
All you have to do to use other people's score files is to set the
gnus-global-score-files
variable. One entry for each score file,
or each score file directory. Gnus will decide by itself what score
files are applicable to which group.
Say you want to use all score files in the `/ftp@ftp.some-where:/pub/score' directory and the single score file `/ftp@ftp.ifi.uio.no:/pub/larsi/ding/score/soc.motss.SCORE':
(setq gnus-global-score-files '("/ftp@ftp.ifi.uio.no:/pub/larsi/ding/score/soc.motss.SCORE" "/ftp@ftp.some-where:/pub/score/"))
Simple, eh? Directory names must end with a `/'. These
directories are typically scanned only once during each Gnus session.
If you feel the need to manually re-scan the remote directories, you can
use the gnus-score-search-global-directories
command.
Note that, at present, using this option will slow down group entry somewhat. (That is--a lot.)
If you want to start maintaining score files for other people to use, just put your score file up for anonymous ftp and announce it to the world. Become a retro-moderator! Participate in the retro-moderator wars sure to ensue, where retro-moderators battle it out for the sympathy of the people, luring them to use their score files on false premises! Yay! The net is saved!
Here are some tips for the would-be retro-moderator, off the top of my head:
Message-ID
.
mark
and expunge
atoms to obliterate the nastiest
articles completely.
... I wonder whether other newsreaders will support global score files in the future. Snicker. Yup, any day now, newsreaders like Blue Wave, xrn and 1stReader are bound to implement scoring. Should we start holding our breath yet?
Gnus still supports those pesky old kill files. In fact, the kill file entries can now be expiring, which is something I wrote before Daniel Quinlan thought of doing score files, so I've left the code in there.
In short, kill processing is a lot slower (and I do mean a lot) than score processing, so it might be a good idea to rewrite your kill files into score files.
Anyway, a kill file is a normal emacs-lisp
file. You can put any
forms into this file, which means that you can use kill files as some
sort of primitive hook function to be run on group entry, even though
that isn't a very good idea.
XCNormal kill files look like this:
(gnus-kill "From" "Lars Ingebrigtsen") (gnus-kill "Subject" "ding") (gnus-expunge "X")
This will mark every article written by me as read, and remove them from the summary buffer. Very useful, you'll agree.
Other programs use a totally different kill file syntax. If Gnus
encounters what looks like a rn
kill file, it will take a stab at
interpreting it.
Two summary functions for editing a GNUS kill file:
gnus-summary-edit-local-kill
).
gnus-summary-edit-global-kill
).
Two group mode functions for editing the kill files:
gnus-group-edit-local-kill
).
gnus-group-edit-global-kill
).
Kill file variables:
gnus-kill-file-name
gnus-kill-file-name
variable.
The "global" kill file (not in the score file sense of "global", of
course) is called just `KILL'.
gnus-kill-save-kill-file
nil
, Gnus will save the
kill file after processing, which is necessary if you use expiring
kills.
gnus-apply-kill-hook
(gnus-apply-kill-file)
by default. If you want to ignore the
kill file if you have a score file for the same group, you can set this
hook to (gnus-apply-kill-file-unless-scored)
. If you don't want
kill files to be processed, you should set this variable to nil
.
gnus-kill-file-mode-hook
GroupLens is a collaborative filtering system that helps you work together with other people to find the quality news articles out of the huge volume of news articles generated every day.
To accomplish this the GroupLens system combines your opinions about articles you have already read with the opinions of others who have done likewise and gives you a personalized prediction for each unread news article. Think of GroupLens as a matchmaker. GroupLens watches how you rate articles, and finds other people that rate articles the same way. Once it has found for you some people you agree with it tells you, in the form of a prediction, what they thought of the article. You can use this prediction to help you decide whether or not you want to read the article.
To use GroupLens you must register a pseudonym with your local Better Bit Bureau (BBB). At the moment the only better bit in town is at `http://www.cs.umn.edu/Research/GroupLens/bbb.html'.
Once you have registered you'll need to set a couple of variables.
gnus-use-grouplens
nil
value will make Gnus hook into
all the relevant GroupLens functions.
grouplens-pseudonym
grouplens-newsgroups
Thats the minimum of what you need to get up and running with GroupLens. Once you've registered, GroupLens will start giving you scores for articles based on the average of what other people think. But, to get the real benefit of GroupLens you need to start rating articles yourself. Then the scores GroupLens gives you will be personalized for you, based on how the people you usually agree with have already rated.
In GroupLens, an article is rated on a scale from 1 to 5, inclusive. Where 1 means something like this article is a waste of bandwidth and 5 means that the article was really good. The basic question to ask yourself is, "on a scale from 1 to 5 would I like to see more articles like this one?"
There are four ways to enter a rating for an article in GroupLens.
The next two commands, n and , take a numerical prefix to be the score of the article you're reading.
If you want to give the current article a score of 4 and then go to the next article, just type 4 n.
GroupLens makes a prediction for you about how much you will like a
news article. The predictions from GroupLens are on a scale from 1 to
5, where 1 is the worst and 5 is the best. You can use the predictions
from GroupLens in one of three ways controlled by the variable
gnus-grouplens-override-scoring
.
There are three ways to display predictions in grouplens. You may
choose to have the GroupLens scores contribute to, or override the
regular gnus scoring mechanism. override is the default; however, some
people prefer to see the Gnus scores plus the grouplens scores. To get
the separate scoring behavior you need to set
gnus-grouplens-override-scoring
to 'separate
. To have the
GroupLens predictions combined with the grouplens scores set it to
'override
and to combine the scores set
gnus-grouplens-override-scoring
to 'combine
. When you use
the combine option you will also want to set the values for
grouplens-prediction-offset
and
grouplens-score-scale-factor
.
In either case, GroupLens gives you a few choices for how you would like
to see your predictions displayed. The display of predictions is
controlled by the grouplens-prediction-display
variable.
The following are legal values for that variable.
prediction-spot
confidence-interval
prediction-bar
confidence-bar
confidence-spot
prediction-num
confidence-plus-minus
gnus-summary-grouplens-line-format
grouplens-bbb-host
grouplens-bbb-port
grouplens-score-offset
grouplens-score-scale-factor
Go to the first, previous, next, last section, table of contents.