This is ../info/gnus, produced by makeinfo version 4.3 from gnus.texi.

INFO-DIR-SECTION Emacs
START-INFO-DIR-ENTRY
* Gnus: (gnus).         The newsreader Gnus.
END-INFO-DIR-ENTRY

   This file documents Gnus, the GNU Emacs newsreader.

   Copyright (C) 1995,96,97,98,99,2000,2001 Free Software Foundation,
Inc.

   Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.1 or
any later version published by the Free Software Foundation; with the
Invariant Sections being none, with the Front-Cover texts being "A GNU
Manual", and with the Back-Cover Texts as in (a) below.  A copy of the
license is included in the section entitled "GNU Free Documentation
License" in the Emacs manual.

   (a) The FSF's Back-Cover Text is: "You have freedom to copy and
modify this GNU Manual, like GNU software.  Copies published by the Free
Software Foundation raise funds for GNU development."

   This document is part of a collection distributed under the GNU Free
Documentation License.  If you want to distribute this document
separately from the collection, you can do so by adding a copy of the
license to the document, as described in section 6 of the license.


File: gnus,  Node: Adaptive Scoring,  Next: Home Score File,  Prev: Score File Editing,  Up: Scoring

Adaptive Scoring
================

   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'
or `(line)'.  If you want score adaptively on separate words appearing
in the subjects, you should set this variable to `(word)'.  If you want
to use both adaptive methods, set this variable to `(word line)'.

   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:

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

   If you have auto-expirable (mail) groups (*note Expiring Mail::), all
the read articles will be marked with the `E' mark.  This'll probably
make adaptive scoring slightly impossible, so auto-expiring and
adaptive scoring doesn't really mix very well.

   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 (*note 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.

   As mentioned above, you can adapt either on individual words or
entire headers.  If you adapt on words, the
`gnus-default-adaptive-word-score-alist' variable says what score each
instance of a word should add given a mark.

     (setq gnus-default-adaptive-word-score-alist
           `((,gnus-read-mark . 30)
             (,gnus-catchup-mark . -10)
             (,gnus-killed-mark . -20)
             (,gnus-del-mark . -15)))

   This is the default value.  If you have adaption on words enabled,
every word that appears in subjects of articles marked with
`gnus-read-mark' will result in a score rule that increase the score
with 30 points.

   Words that appear in the `gnus-default-ignored-adaptive-words' list
will be ignored.  If you wish to add more words to be ignored, use the
`gnus-ignored-adaptive-words' list instead.

   When the scoring is done, `gnus-adaptive-word-syntax-table' is the
syntax table in effect.  It is similar to the standard syntax table, but
it considers numbers to be non-word-constituent characters.

   If `gnus-adaptive-word-minimum' is set to a number, the adaptive
word scoring process will never bring down the score of an article to
below this number.  The default is `nil'.

   If `gnus-adaptive-word-no-group-words' is set to `t', gnus won't
adaptively word score any of the words in the group name.  Useful for
groups like `comp.editors.emacs', where most of the subject lines
contain the word `emacs'.

   After using this scheme for a while, it might be nice to write a
`gnus-psychoanalyze-user' command to go through the rules and see what
words you like and what words you don't like.  Or perhaps not.

   Note that the adaptive word scoring thing is highly experimental and
is likely to change in the future.  Initial impressions seem to indicate
that it's totally useless as it stands.  Some more work (involving more
rigorous statistical methods) will have to be done to make this useful.


File: gnus,  Node: Home Score File,  Next: Followups To Yourself,  Prev: Adaptive Scoring,  Up: Scoring

Home Score File
===============

   The score file where new score file entries will go is called the
"home score file".  This is normally (and by default) the score file
for the group itself.  For instance, the home score file for
`gnu.emacs.gnus' is `gnu.emacs.gnus.SCORE'.

   However, this may not be what you want.  It is often convenient to
share a common home score file among many groups--all `emacs' groups
could perhaps use the same home score file.

   The variable that controls this is `gnus-home-score-file'.  It can
be:

  1. A string.  Then this file will be used as the home score file for
     all groups.

  2. A function.  The result of this function will be used as the home
     score file.  The function will be called with the name of the
     group as the parameter.

  3. A list.  The elements in this list can be:

       1. `(REGEXP FILE-NAME)'.  If the REGEXP matches the group name,
          the FILE-NAME will be used as the home score file.

       2. A function.  If the function returns non-nil, the result will
          be used as the home score file.

       3. A string.  Use the string as the home score file.

     The list will be traversed from the beginning towards the end
     looking for matches.


   So, if you want to use just a single score file, you could say:

     (setq gnus-home-score-file
           "my-total-score-file.SCORE")

   If you want to use `gnu.SCORE' for all `gnu' groups and `rec.SCORE'
for all `rec' groups (and so on), you can say:

     (setq gnus-home-score-file
           'gnus-hierarchial-home-score-file)

   This is a ready-made function provided for your convenience.  Other
functions include

`gnus-current-home-score-file'
     Return the "current" regular score file.  This will make scoring
     commands add entry to the "innermost" matching score file.

   If you want to have one score file for the `emacs' groups and
another for the `comp' groups, while letting all other groups use their
own home score files:

     (setq gnus-home-score-file
           ;; All groups that match the regexp "\\.emacs"
           '(("\\.emacs" "emacs.SCORE")
             ;; All the comp groups in one score file
             ("^comp" "comp.SCORE")))

   `gnus-home-adapt-file' works exactly the same way as
`gnus-home-score-file', but says what the home adaptive score file is
instead.  All new adaptive file entries will go into the file specified
by this variable, and the same syntax is allowed.

   In addition to using `gnus-home-score-file' and
`gnus-home-adapt-file', you can also use group parameters (*note Group
Parameters::) and topic parameters (*note Topic Parameters::) to
achieve much the same.  Group and topic parameters take precedence over
this variable.


File: gnus,  Node: Followups To Yourself,  Next: Scoring Tips,  Prev: Home Score File,  Up: Scoring

Followups To Yourself
=====================

   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'
     This will add a score to articles that directly follow up your own
     article.

`gnus-score-followup-thread'
     This will add a score to all articles that appear in a thread
     "below" your own article.

   These two functions are both primarily meant to be used in hooks like
`message-sent-hook', like this:
     (add-hook 'message-sent-hook 'gnus-score-followup-thread)

   If you look closely at your own `Message-ID', you'll notice that the
first two or three characters are always the same.  Here's two of mine:

     <x6u3u47icf.fsf@eyesore.no>
     <x6sp9o7ibw.fsf@eyesore.no>

   So "my" ident on this machine is `x6'.  This can be exploited--the
following rule will raise the score on all followups to myself:

     ("references"
      ("<x6[0-9a-z]+\\.fsf\\(_-_\\)?@.*eyesore\\.no>"
       1000 nil r))

   Whether it's the first two or first three characters that are "yours"
is system-dependent.


File: gnus,  Node: Scoring Tips,  Next: Reverse Scoring,  Prev: Followups To Yourself,  Up: Scoring

Scoring Tips
============

"Crossposts"
     If you want to lower the score of crossposts, the line to match on
     is the `Xref' header.
          ("xref" (" talk.politics.misc:" -1000))

"Multiple crossposts"
     If you want to lower the score of articles that have been
     crossposted to more than, say, 3 groups:
          ("xref"
            ("[^:\n]+:[0-9]+ +[^:\n]+:[0-9]+ +[^:\n]+:[0-9]+"
             -1000 nil r))

"Matching on the body"
     This is generally not a very good idea--it takes a very long time.
     Gnus actually has to fetch each individual article from the
     server.  But you might want to anyway, I guess.  Even though there
     are three match keys (`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.

"Marking as read"
     You will probably want to mark articles that have scores below a
     certain number as read.  This is most easily achieved by putting
     the following in your `all.SCORE' file:
          ((mark -100))
     You may also consider doing something similar with `expunge'.

"Negated character classes"
     If you say stuff like `[^abcd]*', you may get unexpected results.
     That will match newlines, which might lead to, well, The Unknown.
     Say `[^abcd\n]*' instead.


File: gnus,  Node: Reverse Scoring,  Next: Global Score Files,  Prev: Scoring Tips,  Up: Scoring

Reverse Scoring
===============

   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.


File: gnus,  Node: Global Score Files,  Next: Kill Files,  Prev: Reverse Scoring,  Up: Scoring

Global Score Files
==================

   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.

   To use the score file
`/ftp@ftp.gnus.org:/pub/larsi/ding/score/soc.motss.SCORE' and all score
files in the `/ftp@ftp.some-where:/pub/score' directory, say this:

     (setq gnus-global-score-files
           '("/ftp@ftp.gnus.org:/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:

   * Articles heavily crossposted are probably junk.

   * To lower a single inappropriate article, lower by `Message-ID'.

   * Particularly brilliant authors can be raised on a permanent basis.

   * Authors that repeatedly post off-charter for the group can safely
     be lowered out of existence.

   * Set the `mark' and `expunge' atoms to obliterate the nastiest
     articles completely.

   * Use expiring score entries to keep the size of the file down.  You
     should probably have a long expiry period, though, as some sites
     keep old articles for a long time.

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


File: gnus,  Node: Kill Files,  Next: Converting Kill Files,  Prev: Global Score Files,  Up: Scoring

Kill Files
==========

   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.

   Normal 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 the
marked articles 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:

`M-k'
     Edit this group's kill file (`gnus-summary-edit-local-kill').

`M-K'
     Edit the general kill file (`gnus-summary-edit-global-kill').

   Two group mode functions for editing the kill files:

`M-k'
     Edit this group's kill file (`gnus-group-edit-local-kill').

`M-K'
     Edit the general kill file (`gnus-group-edit-global-kill').

   Kill file variables:

`gnus-kill-file-name'
     A kill file for the group `soc.motss' is normally called
     `soc.motss.KILL'.  The suffix appended to the group name to get
     this file name is detailed by the `gnus-kill-file-name' variable.
     The "global" kill file (not in the score file sense of "global", of
     course) is just called `KILL'.

`gnus-kill-save-kill-file'
     If this variable is non-`nil', Gnus will save the kill file after
     processing, which is necessary if you use expiring kills.

`gnus-apply-kill-hook'
     A hook called to apply kill files to a group.  It is
     `(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'
     A hook called in kill-file mode buffers.


File: gnus,  Node: Converting Kill Files,  Next: GroupLens,  Prev: Kill Files,  Up: Scoring

Converting Kill Files
=====================

   If you have loads of old kill files, you may want to convert them
into score files.  If they are "regular", you can use the
`gnus-kill-to-score.el' package; if not, you'll have to do it by hand.

   The kill to score conversion package isn't included in Gnus by
default.  You can fetch it from
`http://www.stud.ifi.uio.no/~larsi/ding-various/gnus-kill-to-score.el'.

   If your old kill files are very complex--if they contain more
non-`gnus-kill' forms than not, you'll have to convert them by hand.
Or just let them be as they are.  Gnus will still use them as before.


File: gnus,  Node: GroupLens,  Next: Advanced Scoring,  Prev: Converting Kill Files,  Up: Scoring

GroupLens
=========

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

* Menu:

* Using GroupLens::          How to make Gnus use GroupLens.
* Rating Articles::          Letting GroupLens know how you rate articles.
* Displaying Predictions::   Displaying predictions given by GroupLens.
* GroupLens Variables::      Customizing GroupLens.


File: gnus,  Node: Using GroupLens,  Next: Rating Articles,  Up: GroupLens

Using GroupLens
---------------

   To use GroupLens you must register a pseudonym with your local Better
Bit Bureau (BBB).  `http://www.cs.umn.edu/Research/GroupLens/bbb.html'
is the only better bit in town at the moment.

   Once you have registered you'll need to set a couple of variables.

`gnus-use-grouplens'
     Setting this variable to a non-`nil' value will make Gnus hook into
     all the relevant GroupLens functions.

`grouplens-pseudonym'
     This variable should be set to the pseudonym you got when
     registering with the Better Bit Bureau.

`grouplens-newsgroups'
     A list of groups that you want to get GroupLens predictions for.

   That's 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.


File: gnus,  Node: Rating Articles,  Next: Displaying Predictions,  Prev: Using GroupLens,  Up: GroupLens

Rating Articles
---------------

   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.

`r'
     This function will prompt you for a rating on a scale of one to
     five.

`k'
     This function will prompt you for a rating, and rate all the
     articles in the thread.  This is really useful for some of those
     long running giant threads in rec.humor.

   The next two commands, `n' and `,' take a numerical prefix to be the
score of the article you're reading.

`1-5 n'
     Rate the article and go to the next unread article.

`1-5 ,'
     Rate the article and go to the next unread article with the
     highest score.

   If you want to give the current article a score of 4 and then go to
the next article, just type `4 n'.


File: gnus,  Node: Displaying Predictions,  Next: GroupLens Variables,  Prev: Rating Articles,  Up: GroupLens

Displaying Predictions
----------------------

   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 valid values for that variable.

`prediction-spot'
     The higher the prediction, the further to the right an `*' is
     displayed.

`confidence-interval'
     A numeric confidence interval.

`prediction-bar'
     The higher the prediction, the longer the bar.

`confidence-bar'
     Numerical confidence.

`confidence-spot'
     The spot gets bigger with more confidence.

`prediction-num'
     Plain-old numeric value.

`confidence-plus-minus'
     Prediction +/- confidence.


File: gnus,  Node: GroupLens Variables,  Prev: Displaying Predictions,  Up: GroupLens

GroupLens Variables
-------------------

`gnus-summary-grouplens-line-format'
     The summary line format used in GroupLens-enhanced summary
     buffers.  It accepts the same specs as the normal summary line
     format (*note Summary Buffer Lines::).  The default is
     `%U%R%z%l%I%(%[%4L: %-20,20n%]%) %s\n'.

`grouplens-bbb-host'
     Host running the bbbd server.  `grouplens.cs.umn.edu' is the
     default.

`grouplens-bbb-port'
     Port of the host running the bbbd server.  The default is 9000.

`grouplens-score-offset'
     Offset the prediction by this value.  In other words, subtract the
     prediction value by this number to arrive at the effective score.
     The default is 0.

`grouplens-score-scale-factor'
     This variable allows the user to magnify the effect of GroupLens
     scores.  The scale factor is applied after the offset.  The
     default is 1.


File: gnus,  Node: Advanced Scoring,  Next: Score Decays,  Prev: GroupLens,  Up: Scoring

Advanced Scoring
================

   Scoring on Subjects and From headers is nice enough, but what if
you're really interested in what a person has to say only when she's
talking about a particular subject?  Or what if you really don't want to
read what person A has to say when she's following up to person B, but
want to read what she says when she's following up to person C?

   By using advanced scoring rules you may create arbitrarily complex
scoring patterns.

* Menu:

* Advanced Scoring Syntax::     A definition.
* Advanced Scoring Examples::   What they look like.
* Advanced Scoring Tips::       Getting the most out of it.


File: gnus,  Node: Advanced Scoring Syntax,  Next: Advanced Scoring Examples,  Up: Advanced Scoring

Advanced Scoring Syntax
-----------------------

   Ordinary scoring rules have a string as the first element in the
rule.  Advanced scoring rules have a list as the first element.  The
second element is the score to be applied if the first element
evaluated to a non-`nil' value.

   These lists may consist of three logical operators, one redirection
operator, and various match operators.

   Logical operators:

`&'
`and'
     This logical operator will evaluate each of its arguments until it
     finds one that evaluates to `false', and then it'll stop.  If all
     arguments evaluate to `true' values, then this operator will return
     `true'.

`|'
`or'
     This logical operator will evaluate each of its arguments until it
     finds one that evaluates to `true'.  If no arguments are `true',
     then this operator will return `false'.

`!'
`not'
`¬'
     This logical operator only takes a single argument.  It returns the
     logical negation of the value of its argument.

   There is an "indirection operator" that will make its arguments
apply to the ancestors of the current article being scored.  For
instance, `1-' will make score rules apply to the parent of the current
article.  `2-' will make score rules apply to the grandparent of the
current article.  Alternatively, you can write `^^', where the number
of `^'s (carets) says how far back into the ancestry you want to go.

   Finally, we have the match operators.  These are the ones that do the
real work.  Match operators are header name strings followed by a match
and a match type.  A typical match operator looks like `("from" "Lars
Ingebrigtsen" s)'.  The header names are the same as when using simple
scoring, and the match types are also the same.


File: gnus,  Node: Advanced Scoring Examples,  Next: Advanced Scoring Tips,  Prev: Advanced Scoring Syntax,  Up: Advanced Scoring

Advanced Scoring Examples
-------------------------

   Let's say you want to increase the score of articles written by Lars
when he's talking about Gnus:

     ((&
       ("from" "Lars Ingebrigtsen")
       ("subject" "Gnus"))
      1000)

   Quite simple, huh?

   When he writes long articles, he sometimes has something nice to say:

     ((&
       ("from" "Lars Ingebrigtsen")
       (|
        ("subject" "Gnus")
        ("lines" 100 >)))
      1000)

   However, when he responds to things written by Reig Eigil Logge, you
really don't want to read what he's written:

     ((&
       ("from" "Lars Ingebrigtsen")
       (1- ("from" "Reig Eigir Logge")))
      -100000)

   Everybody that follows up Redmondo when he writes about disappearing
socks should have their scores raised, but only when they talk about
white socks.  However, when Lars talks about socks, it's usually not
very interesting:

     ((&
       (1-
        (&
         ("from" "redmondo@.*no" r)
         ("body" "disappearing.*socks" t)))
       (! ("from" "Lars Ingebrigtsen"))
       ("body" "white.*socks"))
      1000)

   The possibilities are endless.


File: gnus,  Node: Advanced Scoring Tips,  Prev: Advanced Scoring Examples,  Up: Advanced Scoring

Advanced Scoring Tips
---------------------

   The `&' and `|' logical operators do short-circuit logic.  That is,
they stop processing their arguments when it's clear what the result of
the operation will be.  For instance, if one of the arguments of an `&'
evaluates to `false', there's no point in evaluating the rest of the
arguments.  This means that you should put slow matches (`body',
`header') last and quick matches (`from', `subject') first.

   The indirection arguments (`1-' and so on) will make their arguments
work on previous generations of the thread.  If you say something like:

     ...
     (1-
      (1-
       ("from" "lars")))
     ...

   Then that means "score on the from header of the grandparent of the
current article".  An indirection is quite fast, but it's better to say:

     (1-
      (&
       ("from" "Lars")
       ("subject" "Gnus")))

   than it is to say:

     (&
      (1- ("from" "Lars"))
      (1- ("subject" "Gnus")))


File: gnus,  Node: Score Decays,  Prev: Advanced Scoring,  Up: Scoring

Score Decays
============

   You may find that your scores have a tendency to grow without
bounds, especially if you're using adaptive scoring.  If scores get too
big, they lose all meaning--they simply max out and it's difficult to
use them in any sensible way.

   Gnus provides a mechanism for decaying scores to help with this
problem.  When score files are loaded and `gnus-decay-scores' is
non-`nil', Gnus will run the score files through the decaying mechanism
thereby lowering the scores of all non-permanent score rules.  The
decay itself if performed by the `gnus-decay-score-function' function,
which is `gnus-decay-score' by default.  Here's the definition of that
function:

     (defun gnus-decay-score (score)
       "Decay SCORE.
     This is done according to `gnus-score-decay-constant'
     and `gnus-score-decay-scale'."
       (floor
        (- score
           (* (if (< score 0) 1 -1)
              (min (abs score)
                   (max gnus-score-decay-constant
                        (* (abs score)
                           gnus-score-decay-scale)))))))

   `gnus-score-decay-constant' is 3 by default and
`gnus-score-decay-scale' is 0.05.  This should cause the following:

  1. Scores between -3 and 3 will be set to 0 when this function is
     called.

  2. Scores with magnitudes between 3 and 60 will be shrunk by 3.

  3. Scores with magnitudes greater than 60 will be shrunk by 5% of the
     score.

   If you don't like this decay function, write your own.  It is called
with the score to be decayed as its only parameter, and it should return
the new score, which should be an integer.

   Gnus will try to decay scores once a day.  If you haven't run Gnus
for four days, Gnus will decay the scores four times, for instance.


File: gnus,  Node: Various,  Next: The End,  Prev: Scoring,  Up: Top

Various
*******

* Menu:

* Process/Prefix::             A convention used by many treatment commands.
* Interactive::                Making Gnus ask you many questions.
* Symbolic Prefixes::          How to supply some Gnus functions with options.
* Formatting Variables::       You can specify what buffers should look like.
* Windows Configuration::      Configuring the Gnus buffer windows.
* Faces and Fonts::            How to change how faces look.
* Compilation::                How to speed Gnus up.
* Mode Lines::                 Displaying information in the mode lines.
* Highlighting and Menus::     Making buffers look all nice and cozy.
* Buttons::                    Get tendonitis in ten easy steps!
* Daemons::                    Gnus can do things behind your back.
* NoCeM::                      How to avoid spam and other fatty foods.
* Undo::                       Some actions can be undone.
* Moderation::                 What to do if you're a moderator.
* Emacs Enhancements::         There can be more pictures and stuff under
                               Emacs 21.
* XEmacs Enhancements::        There are more pictures and stuff under XEmacs.
* Fuzzy Matching::             What's the big fuzz?
* Thwarting Email Spam::       A how-to on avoiding unsolicited commercial email.
* Various Various::            Things that are really various.


File: gnus,  Node: Process/Prefix,  Next: Interactive,  Up: Various

Process/Prefix
==============

   Many functions, among them functions for moving, decoding and saving
articles, use what is known as the "Process/Prefix convention".

   This is a method for figuring out what articles the user wants the
command to be performed on.

   It goes like this:

   If the numeric prefix is N, perform the operation on the next N
articles, starting with the current one.  If the numeric prefix is
negative, perform the operation on the previous N articles, starting
with the current one.

   If `transient-mark-mode' in non-`nil' and the region is active, all
articles in the region will be worked upon.

   If there is no numeric prefix, but some articles are marked with the
process mark, perform the operation on the articles marked with the
process mark.

   If there is neither a numeric prefix nor any articles marked with the
process mark, just perform the operation on the current article.

   Quite simple, really, but it needs to be made clear so that surprises
are avoided.

   Commands that react to the process mark will push the current list of
process marked articles onto a stack and will then clear all process
marked articles.  You can restore the previous configuration with the
`M P y' command (*note Setting Process Marks::).

   One thing that seems to shock & horrify lots of people is that, for
instance, `3 d' does exactly the same as `d' `d' `d'.  Since each `d'
(which marks the current article as read) by default goes to the next
unread article after marking, this means that `3 d' will mark the next
three unread articles as read, no matter what the summary buffer looks
like.  Set `gnus-summary-goto-unread' to `nil' for a more
straightforward action.

   Many commands do not use the process/prefix convention.  All commands
that do explicitly say so in this manual.  To apply the process/prefix
convention to commands that do not use it, you can use the `M-&'
command.  For instance, to mark all the articles in the group as
expirable, you could say `M P b M-& E'.


File: gnus,  Node: Interactive,  Next: Symbolic Prefixes,  Prev: Process/Prefix,  Up: Various

Interactive
===========

`gnus-novice-user'
     If this variable is non-`nil', you are either a newcomer to the
     World of Usenet, or you are very cautious, which is a nice thing
     to be, really.  You will be given questions of the type "Are you
     sure you want to do this?" before doing anything dangerous.  This
     is `t' by default.

`gnus-expert-user'
     If this variable is non-`nil', you will seldom be asked any
     questions by Gnus.  It will simply assume you know what you're
     doing, no matter how strange.

`gnus-interactive-catchup'
     Require confirmation before catching up a group if non-`nil'.  It
     is `t' by default.

`gnus-interactive-exit'
     Require confirmation before exiting Gnus.  This variable is `t' by
     default.


File: gnus,  Node: Symbolic Prefixes,  Next: Formatting Variables,  Prev: Interactive,  Up: Various

Symbolic Prefixes
=================

   Quite a lot of Emacs commands react to the (numeric) prefix.  For
instance, `C-u 4 C-f' moves point four characters forward, and `C-u 9 0
0 I s s p' adds a permanent `Subject' substring score rule of 900 to
the current article.

   This is all nice and well, but what if you want to give a command
some additional information?  Well, what most commands do is interpret
the "raw" prefix in some special way.  `C-u 0 C-x C-s' means that one
doesn't want a backup file to be created when saving the current buffer,
for instance.  But what if you want to save without making a backup
file, and you want Emacs to flash lights and play a nice tune at the
same time?  You can't, and you're probably perfectly happy that way.

   I'm not, so I've added a second prefix--the "symbolic prefix".  The
prefix key is `M-i' (`gnus-symbolic-argument'), and the next character
typed in is the value.  You can stack as many `M-i' prefixes as you
want.  `M-i a M-C-u' means "feed the `M-C-u' command the symbolic
prefix `a'".  `M-i a M-i b M-C-u' means "feed the `M-C-u' command the
symbolic prefixes `a' and `b'".  You get the drift.

   Typing in symbolic prefixes to commands that don't accept them
doesn't hurt, but it doesn't do any good either.  Currently not many
Gnus functions make use of the symbolic prefix.

   If you're interested in how Gnus implements this, *note Extended
Interactive::.


File: gnus,  Node: Formatting Variables,  Next: Windows Configuration,  Prev: Symbolic Prefixes,  Up: Various

Formatting Variables
====================

   Throughout this manual you've probably noticed lots of variables
called things like `gnus-group-line-format' and
`gnus-summary-mode-line-format'.  These control how Gnus is to output
lines in the various buffers.  There's quite a lot of them.
Fortunately, they all use the same syntax, so there's not that much to
be annoyed by.

   Here's an example format spec (from the group buffer): `%M%S%5y:
%(%g%)\n'.  We see that it is indeed extremely ugly, and that there are
lots of percentages everywhere.

* Menu:

* Formatting Basics::     A formatting variable is basically a format string.
* Mode Line Formatting::  Some rules about mode line formatting variables.
* Advanced Formatting::   Modifying output in various ways.
* User-Defined Specs::    Having Gnus call your own functions.
* Formatting Fonts::      Making the formatting look colorful and nice.

   Currently Gnus uses the following formatting variables:
`gnus-group-line-format', `gnus-summary-line-format',
`gnus-server-line-format', `gnus-topic-line-format',
`gnus-group-mode-line-format', `gnus-summary-mode-line-format',
`gnus-article-mode-line-format', `gnus-server-mode-line-format', and
`gnus-summary-pick-line-format'.

   All these format variables can also be arbitrary elisp forms.  In
that case, they will be `eval'ed to insert the required lines.

   Gnus includes a command to help you while creating your own format
specs.  `M-x gnus-update-format' will `eval' the current form, update
the spec in question and pop you to a buffer where you can examine the
resulting lisp code to be run to generate the line.


File: gnus,  Node: Formatting Basics,  Next: Mode Line Formatting,  Up: Formatting Variables

Formatting Basics
-----------------

   Each `%' element will be replaced by some string or other when the
buffer in question is generated.  `%5y' means "insert the `y' spec, and
pad with spaces to get a 5-character field".

   As with normal C and Emacs Lisp formatting strings, the numerical
modifier between the `%' and the formatting type character will "pad"
the output so that it is always at least that long.  `%5y' will make
the field always (at least) five characters wide by padding with spaces
to the left.  If you say `%-5y', it will pad to the right instead.

   You may also wish to limit the length of the field to protect against
particularly wide values.  For that you can say `%4,6y', which means
that the field will never be more than 6 characters wide and never less
than 4 characters wide.


File: gnus,  Node: Mode Line Formatting,  Next: Advanced Formatting,  Prev: Formatting Basics,  Up: Formatting Variables

Mode Line Formatting
--------------------

   Mode line formatting variables (e.g.,
`gnus-summary-mode-line-format') follow the same rules as other, buffer
line oriented formatting variables (*note Formatting Basics::) with the
following two differences:

  1. There must be no newline (`\n') at the end.

  2. The special `%%b' spec can be used to display the buffer name.
     Well, it's no spec at all, really--`%%' is just a way to quote `%'
     to allow it to pass through the formatting machinery unmangled, so
     that Emacs receives `%b', which is something the Emacs mode line
     display interprets to mean "show the buffer name".  For a full
     list of mode line specs Emacs understands, see the documentation
     of the `mode-line-format' variable.



File: gnus,  Node: Advanced Formatting,  Next: User-Defined Specs,  Prev: Mode Line Formatting,  Up: Formatting Variables

Advanced Formatting
-------------------

   It is frequently useful to post-process the fields in some way.
Padding, limiting, cutting off parts and suppressing certain values can
be achieved by using "tilde modifiers".  A typical tilde spec might
look like `%~(cut 3)~(ignore "0")y'.

   These are the valid modifiers:

`pad'
`pad-left'
     Pad the field to the left with spaces until it reaches the required
     length.

`pad-right'
     Pad the field to the right with spaces until it reaches the
     required length.

`max'
`max-left'
     Cut off characters from the left until it reaches the specified
     length.

`max-right'
     Cut off characters from the right until it reaches the specified
     length.

`cut'
`cut-left'
     Cut off the specified number of characters from the left.

`cut-right'
     Cut off the specified number of characters from the right.

`ignore'
     Return an empty string if the field is equal to the specified
     value.

`form'
     Use the specified form as the field value when the `@' spec is
     used.

   Let's take an example.  The `%o' spec in the summary mode lines will
return a date in compact ISO8601 format--`19960809T230410'.  This is
quite a mouthful, so we want to shave off the century number and the
time, leaving us with a six-character date.  That would be `%~(cut-left
2)~(max-right 6)~(pad 6)o'.  (Cutting is done before maxing, and we
need the padding to ensure that the date is never less than 6
characters to make it look nice in columns.)

   Ignoring is done first; then cutting; then maxing; and then as the
very last operation, padding.

   If you use lots of these advanced thingies, you'll find that Gnus
gets quite slow.  This can be helped enormously by running `M-x
gnus-compile' when you are satisfied with the look of your lines.
*Note Compilation::.


File: gnus,  Node: User-Defined Specs,  Next: Formatting Fonts,  Prev: Advanced Formatting,  Up: Formatting Variables

User-Defined Specs
------------------

   All the specs allow for inserting user defined specifiers--`u'.  The
next character in the format string should be a letter.  Gnus will call
the function `gnus-user-format-function-'`X', where `X' is the letter
following `%u'.  The function will be passed a single parameter--what
the parameter means depends on what buffer it's being called from.  The
function should return a string, which will be inserted into the buffer
just like information from any other specifier.  This function may also
be called with dummy values, so it should protect against that.

   You can also use tilde modifiers (*note Advanced Formatting:: to
achieve much the same without defining new functions.  Here's an
example: `%~(form (count-lines (point-min) (point)))@'.  The form given
here will be evaluated to yield the current line number, and then
inserted.


File: gnus,  Node: Formatting Fonts,  Prev: User-Defined Specs,  Up: Formatting Variables

Formatting Fonts
----------------

   There are specs for highlighting, and these are shared by all the
format variables.  Text inside the `%(' and `%)' specifiers will get
the special `mouse-face' property set, which means that it will be
highlighted (with `gnus-mouse-face') when you put the mouse pointer
over it.

   Text inside the `%{' and `%}' specifiers will have their normal
faces set using `gnus-face-0', which is `bold' by default.  If you say
`%1{', you'll get `gnus-face-1' instead, and so on.  Create as many
faces as you wish.  The same goes for the `mouse-face' specs--you can
say `%3(hello%)' to have `hello' mouse-highlighted with
`gnus-mouse-face-3'.

   Text inside the `%<' and `%>' specifiers will get the special
`balloon-help' property set to `gnus-balloon-face-0'.  If you say
`%1<', you'll get `gnus-balloon-face-1' and so on.  The
`gnus-balloon-face-*' variables should be either strings or symbols
naming functions that return a string.  Under `balloon-help-mode', when
the mouse passes over text with this property set, a balloon window
will appear and display the string.  Please refer to the doc string of
`balloon-help-mode' for more information on this.

   Here's an alternative recipe for the group buffer:

     ;; Create three face types.
     (setq gnus-face-1 'bold)
     (setq gnus-face-3 'italic)
     
     ;; We want the article count to be in
     ;; a bold and green face.  So we create
     ;; a new face called `my-green-bold'.
     (copy-face 'bold 'my-green-bold)
     ;; Set the color.
     (set-face-foreground 'my-green-bold "ForestGreen")
     (setq gnus-face-2 'my-green-bold)
     
     ;; Set the new & fancy format.
     (setq gnus-group-line-format
           "%M%S%3{%5y%}%2[:%] %(%1{%g%}%)\n")

   I'm sure you'll be able to use this scheme to create totally
unreadable and extremely vulgar displays.  Have fun!

   Note that the `%(' specs (and friends) do not make any sense on the
mode-line variables.

