A line for each article is displayed in the summary buffer. You can move around, read articles, post articles and reply to articles.
The most common way to a summary buffer is to select a group from the group buffer (see section Selecting a Group).
You can have as many summary buffers open as you wish.
Gnus will use the value of the gnus-extract-address-components
variable as a function for getting the name and address parts of a
From
header. Two pre-defined function exist:
gnus-extract-address-components
, which is the default, quite
fast, and too simplistic solution; and
mail-extract-address-components
, which works very nicely, but is
slower. The default function will return the wrong answer in 5% of the
cases. If this is unacceptable to you, use the other function instead.
gnus-summary-same-subject
is a string indicating that the current
article has the same subject as the previous. This string will be used
with those specs that require it. The default is `'.
You can change the format of the lines in the summary buffer by changing
the gnus-summary-line-format
variable. It works along the same
lines a a normal format
string, with some extensions
(see section Formatting Variables).
The default string is `%U%R%z%I%(%[%4L: %-20,20n%]%) %s\n'.
The following format specification characters are understood:
gnus-summary-same-subject
otherwise.
(gnus-summary-same-subject
defaults to `'.)
From
header.
From
header).
From
header). This differs from the n
spec in that it uses the function designated by the
gnus-extract-address-components
variable, which is slower, but
may be more thorough.
From
header). This works the same way as
the a
spec.
gnus-summary-default-level
and the score is less than
gnus-summary-zcore-fuzz
, this spec will not be used.
Xref
.
Date
.
Date
in DD-MMM
format.
Date
in YYYYMMDDTHHMMSS
format.
Message-ID
.
References
.
gnus-not-empty-thread-mark
) will be displayed if the
article has any children.
gnus-user-format-function-
`X', where `X' is the letter
following `%u'. The function will be passed the current header as
argument. The function should return a string, which will be inserted
into the summary just like information from any other summary specifier.
The `%U' (status), `%R' (replied) and `%z' (zcore) specs have to be handled with care. For reasons of efficiency, Gnus will compute what column these characters will end up in, and "hard-code" that. This means that it is illegal to have these specs after a variable-length spec. Well, you might not be arrested, but your summary buffer will look strange, which is bad enough.
The smart choice is to have these specs as far to the left as possible. (Isn't that the case with everything, though? But I digress.)
This restriction may disappear in later versions of Gnus.
You can also change the format of the summary mode bar. Set
gnus-summary-mode-line-format
to whatever you like. The default
is `Gnus: %%b [%A] %Z'.
Here are the elements you can play with:
gnus-visual-mark-article-hook
gnus-visual
is nil
.
gnus-summary-update-hook
gnus-visual
is nil
.
gnus-summary-selected-face
gnus-summary-highlight
(((eq mark gnus-ticked-mark) . italic) ((> score default) . bold))As you may have guessed, if FORM returns a non-
nil
value,
FACE will be applied to the line.
All the straight movement commands understand the numeric prefix and behave pretty much as you'd expect.
None of these commands select articles.
gnus-summary-next-unread-subject
).
gnus-summary-prev-unread-subject
).
gnus-summary-goto-article
).
gnus-summary-goto-subject
).
If Gnus asks you to press a key to confirm going to the next group, you can use the C-n and C-p keys to move around the group buffer, searching for the next group to read without actually returning to the group buffer.
Variables related to summary movement:
gnus-auto-select-next
t
and the next group is
empty, Gnus will exit summary mode and return to the group buffer. If
this variable is neither t
nor nil
, Gnus will select the
next group, no matter whether it has any unread articles or not. As a
special case, if this variable is quietly
, Gnus will select the
next group without asking for confirmation. If this variable is
almost-quietly
, the same will happen only if you are located on
the last article in the group. Finally, if this variable is
slightly-quietly
, the Z n command will go to the next group
without confirmation. Also see section Group Levels.
gnus-auto-select-same
nil
, all the movement commands will try to go to the next
article with the same subject as the current. (Same here might
mean roughly equal. See gnus-summary-gather-subject-limit
for details (see section Customizing Threading).) This variable is not
particularly useful if you use a threaded display.
gnus-summary-check-current
nil
, all the "unread" movement commands will not proceed
to the next (or previous) article if the current article is unread.
Instead, they will choose the current article.
gnus-auto-center-summary
nil
, Gnus will keep the point in the summary buffer
centered at all times. This makes things quite tidy, but if you have a
slow network connection, or simply do not like this un-Emacsism, you can
set this variable to nil
to get the normal Emacs scrolling
action. This will also inhibit horizontal re-centering of the summary
buffer, which might make it more inconvenient to read extremely long
threads.
None of the following movement commands understand the numeric prefix, and they all select and display an article.
gnus-summary-next-page
).
gnus-summary-next-unread-article
).
gnus-summary-prev-unread-article
).
gnus-summary-next-article
).
gnus-summary-prev-article
).
gnus-summary-next-same-subject
).
gnus-summary-prev-same-subject
).
gnus-summary-first-unread-article
).
gnus-summary-best-unread-article
).
gnus-summary-goto-last-article
).
gnus-summary-pop-article
). This command differs from the
command above in that you can pop as many previous articles off the
history as you like.
Some variables that are relevant for moving and selecting articles:
gnus-auto-extend-newsgroup
nil
. Gnus will then fetch the article from
the server and display it in the article buffer.
gnus-select-article-hook
gnus-mark-article-hook
gnus-summary-mark-read-and-unread-as-read
, and will change the
mark of almost any article you read to gnus-unread-mark
. The
only articles not affected by this function are ticked, dormant, and
expirable articles. If you'd instead like to just have unread articles
marked as read, you can use gnus-summary-mark-unread-as-read
instead. It will leave marks like gnus-low-score-mark
,
gnus-del-mark
(and so on) alone.
gnus-summary-next-page
).
gnus-summary-prev-page
).
gnus-summary-scroll-up
).
gnus-summary-show-article
). If
given a prefix, fetch the current article, but don't run any of the
article treatment functions. This will give you a "raw" article, just
the way it came from the server.
gnus-summary-beginning-of-article
).
gnus-summary-end-of-article
).
gnus-summary-isearch-article
).
Commands for composing a mail message:
gnus-summary-reply
).
gnus-summary-reply-with-original
). This
command uses the process/prefix convention.
gnus-summary-wide-reply
).
gnus-summary-reply-with-original
). This command uses
the process/prefix convention.
gnus-summary-mail-forward
). If given a prefix, include the full
headers of the forwarded article.
gnus-summary-mail-other-window
).
gnus-summary-resend-bounced-mail
). You
will be popped into a mail buffer where you can edit the headers before
sending the mail off again. If you give a prefix to this command, and
the bounced mail is a reply to some other mail, Gnus will try to fetch
that mail and display it for easy perusal of its headers. This might
very well fail, though.
gnus-summary-resend-message
will prompt you for an address to
send the current message off to, and then send it to that place. The
headers of the message won't be altered--but lots of headers that say
Resent-To
, Resent-From
and so on will be added. This
means that you actually send a mail to someone that has a To
header that (probably) points to yourself. This will confuse people.
So, natcherly you'll only do that if you're really eVIl.
This command is mainly used if you have several accounts and want to
ship a mail to a different account of yours. (If you're both
root
and postmaster
and get a mail for postmaster
to the root
account, you may want to resend it to
postmaster
. Ordnung muß sein!
This command understands the process/prefix convention
(see section Process/Prefix).
gnus-uu-digest-mail-forward
). This command uses the
process/prefix convention (see section Process/Prefix).
gnus-summary-mail-crosspost-complaint
).
This command is provided as a way to fight back agains the current
crossposting pandemic that's sweeping Usenet. It will compose a reply
using the gnus-crosspost-complaint
variable as a preamble. This
command understands the process/prefix convention
(see section Process/Prefix) and will prompt you before sending each mail.
Commands for posting a news article:
gnus-summary-post-news
).
gnus-summary-followup
).
gnus-summary-followup-with-original
). This command uses the
process/prefix convention.
gnus-summary-followup-to-mail
).
gnus-summary-followup-to-mail-with-original
). This command uses
the process/prefix convention.
gnus-summary-post-forward
). If given a prefix, include the full
headers of the forwarded article.
gnus-uu-digest-mail-forward
).
gnus-uu-post-news
). (see section Uuencoding and Posting).
Have you ever written something, and then decided that you really, really, really wish you hadn't posted that?
Well, you can't cancel mail, but you can cancel posts.
Find the article you wish to cancel (you can only cancel your own
articles, so don't try any funny stuff). Then press C or S
c (gnus-summary-cancel-article
). Your article will be
canceled--machines all over the world will be deleting your article.
Be aware, however, that not all sites honor cancels, so your article may live on here and there, while most sites will delete the article in question.
If you discover that you have made some mistakes and want to do some corrections, you can post a superseding article that will replace your original article.
Go to the original article and press S s
(gnus-summary-supersede-article
). You will be put in a buffer
where you can edit the article all you want before sending it off the
usual way.
The same goes for superseding as for canceling, only more so: Some sites do not honor superseding. On those sites, it will appear that you have posted almost the same article twice.
If you have just posted the article, and change your mind right away,
there is a trick you can use to cancel/supersede the article without
waiting for the article to appear on your site first. You simply return
to the post buffer (which is called *sent ...*
). There you will
find the article you just posted, with all the headers intact. Change
the Message-ID
header to a Cancel
or Supersedes
header by substituting one of those words for the word
Message-ID
. Then just press C-c C-c to send the article as
you would do normally. The previous article will be
canceled/superseded.
Just remember, kids: There is no 'c' in 'supersede'.
There are several marks you can set on an article.
You have marks that decide the readedness (whoo, neato-keano neologism ohoy!) of the article. Alphabetic marks generally mean read, while non-alphabetic characters generally mean unread.
In addition, you also have marks that do not affect readedness.
The following marks mark articles as (kinda) unread, in one form or other.
gnus-ticked-mark
).
Ticked articles are articles that will remain visible always. If
you see an article that you find interesting, or you want to put off
reading it, or replying to it, until sometime later, you'd typically
tick it. However, articles can be expired, so if you want to keep an
article forever, you'll have to make it persistent (see section Persistent Articles).
gnus-dormant-mark
).
Dormant articles will only appear in the summary buffer if there
are followups to it.
gnus-unread-mark
).
Unread articles are articles that haven't been read at all yet.
All the following marks mark articles as read.
gnus-del-mark
).
gnus-read-mark
).
gnus-ancient-mark
).
gnus-killed-mark
).
gnus-kill-file-mark
).
gnus-low-score-mark
).
gnus-catchup-mark
).
gnus-canceled-mark
)
gnus-souped-mark
). See section SOUP.
gnus-sparse-mark
). See section Customizing Threading.
gnus-duplicated-mark
). See section Duplicate Suppression.
All these marks just mean that the article is marked as read, really. They are interpreted differently when doing adaptive scoring, though.
One more special mark, though:
gnus-expirable-mark
).
Marking articles as expirable (or have them marked as such
automatically) doesn't make much sense in normal groups--a user doesn't
control the expiring of news articles, but in mail groups, for instance,
articles that are marked as expirable can be deleted by Gnus at
any time.
There are some marks that have nothing to do with whether the article is read or not.
gnus-replied-mark
).
gnus-cached-mark
).
gnus-saved-mark
.
gnus-not-empty-thread-mark
and
gnus-empty-thread-mark
in the third column, respectively.
gnus-process-mark
. A
variety of commands react to the presence of the process mark. For
instance, X u (gnus-uu-decode-uu
) will uudecode and view
all articles that have been marked with the process mark. Articles
marked with the process mark have a `#' in the second column.
You might have noticed that most of these "non-readedness" marks appear in the second column by default. So if you have a cached, saved, replied article that you have process-marked, what will that look like?
Nothing much. The precedence rules go as follows: process -> cache -> replied -> saved. So if the article is in the cache and is replied, you'll only see the cache mark and not the replied mark.
All the marking commands understand the numeric prefix.
gnus-summary-tick-article-forward
).
gnus-summary-mark-as-dormant
).
gnus-summary-mark-as-read-forward
).
gnus-summary-mark-as-read-backward
).
gnus-summary-kill-same-subject-and-select
).
gnus-summary-kill-same-subject
).
gnus-summary-catchup
).
gnus-summary-catchup-all
).
gnus-summary-catchup-to-here
).
gnus-summary-mark-region-as-read
).
gnus-summary-kill-below
).
gnus-summary-clear-mark-forward
).
gnus-summary-mark-as-expirable
).
gnus-summary-set-bookmark
).
gnus-summary-remove-bookmark
).
gnus-summary-clear-above
).
gnus-summary-tick-above
).
gnus-summary-clear-above
).
The gnus-summary-goto-unread
variable controls what action should
be taken after setting a mark. If non-nil
, point will move to
the next/previous unread article. If nil
, point will just move
one line up or down. As a special case, if this variable is
never
, all the marking commands as well as other commands (like
SPACE) will move to the next article, whether it is unread or not.
The default is t
.
gnus-summary-mark-as-processable
).
gnus-summary-unmark-as-processable
).
gnus-summary-unmark-all-processable
).
gnus-uu-invert-processable
).
gnus-uu-mark-by-regexp
).
gnus-uu-mark-region
).
gnus-uu-mark-thread
).
gnus-uu-unmark-thread
).
gnus-uu-mark-over
).
gnus-uu-mark-series
).
gnus-uu-mark-sparse
).
gnus-uu-mark-series
).
gnus-uu-mark-buffer
).
gnus-summary-kill-process-mark
).
gnus-summary-yank-process-mark
).
gnus-summary-save-process-mark
).
It can be convenient to limit the summary buffer to just show some subset of the articles currently in the group. The effect most limit commands have is to remove a few (or many) articles from the summary buffer.
gnus-summary-limit-to-subject
).
gnus-summary-limit-to-author
).
gnus-summary-limit-to-unread
). If given a prefix, limit the
buffer to articles that are strictly unread. This means that ticked and
dormant articles will also be excluded.
gnus-summary-limit-to-marks
).
gnus-summary-limit-to-marks
). If given a prefix, limit to
articles that are younger than that number of days.
gnus-summary-limit-to-articles
). Uses the process/prefix
convention (see section Process/Prefix).
gnus-summary-pop-limit
). If given a prefix, pop all limits off
the stack.
gnus-summary-limit-to-score
).
gnus-summary-limit-include-expunged
).
gnus-summary-limit-include-dormant
).
gnus-summary-limit-exclude-dormant
).
gnus-summary-limit-exclude-childless-dormant
).
gnus-summary-limit-mark-excluded-as-read
). If given a prefix,
also mark excluded ticked and dormant articles as read.
Gnus threads articles by default. To thread is to put responses to articles directly after the articles they respond to--in a hierarchical fashion.
gnus-show-threads
nil
, no threading will be done, and all of
the rest of the variables here will have no effect. Turning threading
off will speed group selection up a bit, but it is sure to make reading
slower and more awkward.
gnus-fetch-old-headers
nil
, Gnus will attempt to build old threads by fetching
more old headers--headers to articles that are marked as read. If you
would like to display as few summary lines as possible, but still
connect as many loose threads as possible, you should set this variable
to some
or a number. If you set it to a number, no more than
that number of extra old headers will be fetched. In either case,
fetching old headers only works if the backend you are using carries
overview files--this would normally be nntp
, nnspool
and
nnml
. Also remember that if the root of the thread has been
expired by the server, there's not much Gnus can do about that.
gnus-build-sparse-threads
some
. Gnus will then look at
the complete References
headers of all articles and try to string
articles that belong in the same thread together. This will leave
gaps in the threading display where Gnus guesses that an article
is missing from the thread. (These gaps appear like normal summary
lines. If you select a gap, Gnus will try to fetch the article in
question.) If this variable is t
, Gnus will display all these
"gaps" without regard for whether they are useful for completing the
thread or not. Finally, if this variable is more
, Gnus won't cut
off sparse leaf nodes that don't lead anywhere. This variable is
nil
by default.
gnus-summary-gather-subject-limit
nil
, Gnus requires an exact match between the
subjects of the loose threads before gathering them into one big
super-thread. This might be too strict a requirement, what with the
presence of stupid newsreaders that chop off long subjects lines. If
you think so, set this variable to, say, 20 to require that only the
first 20 characters of the subjects have to match. If you set this
variable to a really low number, you'll find that Gnus will gather
everything in sight into one thread, which isn't very helpful.
If you set this variable to the special value fuzzy
, Gnus will
use a fuzzy string comparison algorithm on the subjects (see section Fuzzy Matching).
gnus-simplify-subject-fuzzy-regexp
gnus-simplify-ignored-prefixes
gnus-summary-gather-subject-limit
to something as low
as 10, you might consider setting this variable to something sensible:
(setq gnus-simplify-ignored-prefixes (concat "\\`\\[?\\(" (mapconcat 'identity '("looking" "wanted" "followup" "summary\\( of\\)?" "help" "query" "problem" "question" "answer" "reference" "announce" "How can I" "How to" "Comparison of" ;; ... ) "\\|") "\\)\\s *\\(" (mapconcat 'identity '("for" "for reference" "with" "about") "\\|") "\\)?\\]?:?[ \t]*"))All words that match this regexp will be removed before comparing two subjects.
gnus-summary-gather-exclude-subject
gnus-summary-gather-exclude-subject
to say
what subjects should be excluded from the gathering process. The
default is `^ *$\\|^(none)$'.
gnus-summary-thread-gathering-function
Subject
headers. This means
that totally unrelated articles may end up in the same "thread", which
is confusing. An alternate approach is to look at all the
Message-ID
s in all the References
headers to find matches.
This will ensure that no gathered threads ever includes unrelated
articles, but it's also means that people who have posted with broken
newsreaders won't be gathered properly. The choice is yours--plague or
cholera:
gnus-gather-threads-by-subject
Subject
s exclusively.
gnus-gather-threads-by-references
References
headers exclusively.
References
, you could say
something like:
(setq gnus-summary-thread-gathering-function 'gnus-gather-threads-by-references)
gnus-summary-make-false-root
nil
, Gnus will gather all loose subtrees into one big tree
and create a dummy root at the top. (Wait a minute. Root at the top?
Yup.) Loose subtrees occur when the real root has expired, or you've
read or killed the root in a previous session.
When there is no real root of a thread, Gnus will have to fudge
something. This variable says what fudging method Gnus should use.
There are four possible values:
adopt
dummy
gnus-summary-dummy-line-format
is used to specify the
format of the dummy roots. It accepts only one format spec: `S',
which is the subject of the article. See section Formatting Variables.
empty
gnus-summary-same-subject
as the subject (see section Summary Buffer Format).)
none
nil
gnus-thread-hide-subtree
nil
, all threads will be hidden when the summary buffer is
generated.
gnus-thread-expunge-below
gnus-thread-score-function
) less than this number will be
expunged. This variable is nil
by default, which means that no
threads are expunged.
gnus-thread-hide-killed
nil
, the subtree
will be hidden.
gnus-thread-ignore-subject
nil
, the subject change is ignored. If it
is nil
, which is the default, a change in the subject will result
in a new thread.
gnus-thread-indent-level
gnus-parse-headers-hook
(gnus-decode-rfc1522)
, which means that QPized headers will be
slightly decoded in a hackish way. This is likely to change in the
future when Gnus becomes MIMEified.
gnus-summary-kill-thread
). If the prefix argument is positive,
remove all marks instead. If the prefix argument is negative, tick
articles instead.
gnus-summary-lower-thread
).
gnus-summary-raise-thread
).
gnus-uu-mark-thread
).
gnus-uu-unmark-thread
).
gnus-summary-toggle-threads
).
gnus-summary-show-thread
).
gnus-summary-hide-thread
).
gnus-summary-show-all-threads
).
gnus-summary-hide-all-threads
).
gnus-summary-rethread-current
). This works even when the
summary buffer is otherwise unthreaded.
gnus-summary-reparent-thread
.
The following commands are thread movement commands. They all understand the numeric prefix.
gnus-summary-next-thread
).
gnus-summary-prev-thread
).
gnus-summary-down-thread
).
gnus-summary-up-thread
).
gnus-summary-top-thread
).
If you ignore subject while threading, you'll naturally end up with
threads that have several different subjects in them. If you then issue
a command like `T k' (gnus-summary-kill-thread
) you might not
wish to kill the entire thread, but just those parts of the thread that
have the same subject as the current article. If you like this idea,
you can fiddle with gnus-thread-operation-ignore-subject
. If is
is non-nil
(which it is by default), subjects will be ignored
when doing thread commands. If this variable is nil
, articles in
the same thread with different subjects will not be included in the
operation in question. If this variable is fuzzy
, only articles
that have subjects that are fuzzily equal will be included (see section Fuzzy Matching).
If you are using a threaded summary display, you can sort the threads by
setting gnus-thread-sort-functions
, which is a list of functions.
By default, sorting is done on article numbers. Ready-made sorting
predicate functions include gnus-thread-sort-by-number
,
gnus-thread-sort-by-author
, gnus-thread-sort-by-subject
,
gnus-thread-sort-by-date
, gnus-thread-sort-by-score
, and
gnus-thread-sort-by-total-score
.
Each function takes two threads and return non-nil
if the first
thread should be sorted before the other. Note that sorting really is
normally done by looking only at the roots of each thread. If you use
more than one function, the primary sort key should be the last function
in the list. You should probably always include
gnus-thread-sort-by-number
in the list of sorting
functions--preferably first. This will ensure that threads that are
equal with respect to the other sort criteria will be displayed in
ascending article order.
If you would like to sort by score, then by subject, and finally by number, you could do something like:
(setq gnus-thread-sort-functions '(gnus-thread-sort-by-number gnus-thread-sort-by-subject gnus-thread-sort-by-total-score))
The threads that have highest score will be displayed first in the summary buffer. When threads have the same score, they will be sorted alphabetically. The threads that have the same score and the same subject will be sorted by number, which is (normally) the sequence in which the articles arrived.
If you want to sort by score and then reverse arrival order, you could say something like:
(setq gnus-thread-sort-functions '((lambda (t1 t2) (not (gnus-thread-sort-by-number t1 t2))) gnus-thread-sort-by-score))
The function in the gnus-thread-score-function
variable (default
+
) is used for calculating the total score of a thread. Useful
functions might be max
, min
, or squared means, or whatever
tickles your fancy.
If you are using an unthreaded display for some strange reason or other,
you have to fiddle with the gnus-article-sort-functions
variable.
It is very similar to the gnus-thread-sort-functions
, except that
is uses slightly different functions for article comparison. Available
sorting predicate functions are gnus-article-sort-by-number
,
gnus-article-sort-by-author
, gnus-article-sort-by-subject
,
gnus-article-sort-by-date
, and gnus-article-sort-by-score
.
If you want to sort an unthreaded summary display by subject, you could say something like:
(setq gnus-article-sort-functions '(gnus-article-sort-by-number gnus-article-sort-by-subject))
If you read your news from an NNTP server that's far away, the network latencies may make reading articles a chore. You have to wait for a while after pressing n to go to the next article before the article appears. Why can't Gnus just go ahead and fetch the article while you are reading the previous one? Why not, indeed.
First, some caveats. There are some pitfalls to using asynchronous article fetching, especially the way Gnus does it.
Let's say you are reading article 1, which is short, and article 2 is quite long, and you are not interested in reading that. Gnus does not know this, so it goes ahead and fetches article 2. You decide to read article 3, but since Gnus is in the process of fetching article 2, the connection is blocked.
To avoid these situations, Gnus will open two (count 'em two) connections to the server. Some people may think this isn't a very nice thing to do, but I don't see any real alternatives. Setting up that extra connection takes some time, so Gnus startup will be slower.
Gnus will fetch more articles than you will read. This will mean that the link between your machine and the NNTP server will become more loaded than if you didn't use article pre-fetch. The server itself will also become more loaded--both with the extra article requests, and the extra connection.
Ok, so now you know that you shouldn't really use this thing... unless you really want to.
Here's how: Set gnus-asynchronous
to t
. The rest should
happen automatically.
You can control how many articles that are to be pre-fetched by setting
gnus-use-article-prefetch
. This is 30 by default, which means
that when you read an article in the group, the backend will pre-fetch
the next 30 articles. If this variable is t
, the backend will
pre-fetch all the articles that it can without bound. If it is
nil
, no pre-fetching will be made.
There are probably some articles that you don't want to pre-fetch--read
articles, for instance. Which articles to pre-fetch is controlled by
the gnus-async-prefetch-article-p
variable. This function should
return non-nil
when the article in question is to be
pre-fetched. The default is gnus-async-read-p
, which returns
nil
on read articles. The function is called with an article
data structure as the only parameter.
If, for instance, you wish to pre-fetch only unread articles that are shorter than 100 lines, you could say something like:
(defun my-async-short-unread-p (data) "Return non-nil for short, unread articles." (and (gnus-data-unread-p data) (< (mail-header-lines (gnus-data-header data)) 100))) (setq gnus-async-prefetch-article-p 'my-async-short-unread-p)
These functions will be called many, many times, so they should preferrably be short and sweet to avoid slowing down Gnus too much. It's also probably a good idea to byte-compile things like this.
Articles have to be removed from the asynch buffer sooner or later. The
gnus-prefetched-article-deletion-strategy
says when to remove
articles. This is a list that may contain the following elements:
read
exit
The default value is (read exit)
.
If gnus-use-header-prefetch
is non-nil
, prefetch articles
from the next group.
If you have an extremely slow NNTP connection, you may consider turning article caching on. Each article will then be stored locally under your home directory. As you may surmise, this could potentially use huge amounts of disk space, as well as eat up all your inodes so fast it will make your head swim. In vodka.
Used carefully, though, it could be just an easier way to save articles.
To turn caching on, set gnus-use-cache
to t
. By default,
all articles that are ticked or marked as dormant will then be copied
over to your local cache (gnus-cache-directory
). Whether this
cache is flat or hierarchal is controlled by the
gnus-use-long-file-name
variable, as usual.
When re-select a ticked or dormant article, it will be fetched from the cache instead of from the server. As articles in your cache will never expire, this might serve as a method of saving articles while still keeping them where they belong. Just mark all articles you want to save as dormant, and don't worry.
When an article is marked as read, is it removed from the cache.
The entering/removal of articles from the cache is controlled by the
gnus-cache-enter-articles
and gnus-cache-remove-articles
variables. Both are lists of symbols. The first is (ticked
dormant)
by default, meaning that ticked and dormant articles will be
put in the cache. The latter is (read)
by default, meaning that
articles that are marked as read are removed from the cache. Possibly
symbols in these two lists are ticked
, dormant
,
unread
and read
.
So where does the massive article-fetching and storing come into the
picture? The gnus-jog-cache
command will go through all
subscribed newsgroups, request all unread articles, and store them in
the cache. You should only ever, ever ever ever, use this command if 1)
your connection to the NNTP server is really, really, really slow
and 2) you have a really, really, really huge disk. Seriously.
It is likely that you do not want caching on some groups. For instance,
if your nnml
mail is located under your home directory, it makes no
sense to cache it somewhere else under your home directory. Unless you
feel that it's neat to use twice as much space. To limit the caching,
you could set the gnus-uncacheable-groups
regexp to
`^nnml', for instance. This variable is nil
by
default.
The cache stores information on what articles it contains in its active
file (gnus-cache-active-file
). If this file (or any other parts
of the cache) becomes all messed up for some reason or other, Gnus
offers two functions that will try to set things right. M-x
gnus-cache-generate-nov-databases will (re)build all the NOV
files, and gnus-cache-generate-active will (re)generate the active
file.
Closely related to article caching, we have persistent articles. In fact, it's just a different way of looking at caching, and much more useful in my opinion.
Say you're reading a newsgroup, and you happen on to some valuable gem that you want to keep and treasure forever. You'd normally just save it (using one of the many saving commands) in some file. The problem with that is that it's just, well, yucky. Ideally you'd prefer just having the article remain in the group where you found it forever; untouched by the expiry going on at the news server.
This is what a persistent article is--an article that just won't be deleted. It's implemented using the normal cache functions, but you use two explicit commands for managing persistent articles:
gnus-cache-enter-article
).
gnus-cache-remove-article
). This will normally delete the
article.
Both these commands understand the process/prefix convention.
To avoid having all ticked articles (and stuff) entered into the cache,
you should set gnus-use-cache
to passive
if you're just
interested in persistent articles:
(setq gnus-use-cache 'passive)
If you have a slow connection, but the idea of using caching seems unappealing to you (and it is, really), you can help the situation some by switching on the backlog. This is where Gnus will buffer already read articles so that it doesn't have to re-fetch articles you've already read. This only helps if you are in the habit of re-selecting articles you've recently read, of course. If you never do that, turning the backlog on will slow Gnus down a little bit, and increase memory usage some.
If you set gnus-keep-backlog
to a number n, Gnus will store
at most n old articles in a buffer for later re-fetching. If this
variable is non-nil
and is not a number, Gnus will store
all read articles, which means that your Emacs will grow without
bound before exploding and taking your machine down with you. I put
that in there just to keep y'all on your toes.
This variable is nil
by default.
Gnus can save articles in a number of ways. Below is the documentation
for saving articles in a fairly straight-forward fashion (i.e., little
processing of the article is done before it is saved). For a different
approach (uudecoding, unsharing) you should use gnus-uu
(see section Decoding Articles).
If gnus-save-all-headers
is non-nil
, Gnus will not delete
unwanted headers before saving the article.
If the preceding variable is nil
, all headers that match the
gnus-saved-headers
regexp will be kept, while the rest will be
deleted before saving.
gnus-summary-save-article
).
gnus-summary-save-article-mail
).
gnus-summary-save-article-rmail
).
gnus-summary-save-article-file
).
gnus-summary-write-article-file
).
gnus-summary-save-article-body-file
).
gnus-summary-save-article-folder
).
gnus-summary-save-article-vm
).
gnus-summary-pipe-output
).
All these commands use the process/prefix convention
(see section Process/Prefix). If you save bunches of articles using these
functions, you might get tired of being prompted for files to save each
and every article in. The prompting action is controlled by
the gnus-prompt-before-saving
variable, which is always
by
default, giving you that excessive prompting action you know and
loathe. If you set this variable to t
instead, you'll be prompted
just once for each series of articles you save. If you like to really
have Gnus do all your thinking for you, you can even set this variable
to nil
, which means that you will never be prompted for files to
save articles in. Gnus will simply save all the articles in the default
files.
You can customize the gnus-default-article-saver
variable to make
Gnus do what you want it to. You can use any of the four ready-made
functions below, or you can create your own.
gnus-summary-save-in-rmail
gnus-rmail-save-name
variable to get a file name to save the
article in. The default is gnus-plain-save-name
.
gnus-summary-save-in-mail
gnus-mail-save-name
variable to get a file name to save the
article in. The default is gnus-plain-save-name
.
gnus-summary-save-in-file
gnus-file-save-name
variable to get a file name to save the
article in. The default is gnus-numeric-save-name
.
gnus-summary-save-body-in-file
gnus-file-save-name
variable to get a file name to save the
article in. The default is gnus-numeric-save-name
.
gnus-summary-save-in-folder
rcvstore
from the MH
library. Uses the function in the gnus-folder-save-name
variable
to get a file name to save the article in. The default is
gnus-folder-save-name
, but you can also use
gnus-Folder-save-name
. The former creates capitalized names, and
the latter does not.
gnus-summary-save-in-vm
All of these functions, except for the last one, will save the article
in the gnus-article-save-directory
, which is initialized from the
SAVEDIR
environment variable. This is `~/News/' by
default.
As you can see above, the functions use different functions to find a suitable name of a file to save the article in. Below is a list of available functions that generate names:
gnus-Numeric-save-name
gnus-numeric-save-name
gnus-Plain-save-name
gnus-plain-save-name
You can have Gnus suggest where to save articles by plonking a regexp into
the gnus-split-methods
alist. For instance, if you would like to
save articles related to Gnus in the file `gnus-stuff', and articles
related to VM in vm-stuff
, you could set this variable to something
like:
(("^Subject:.*gnus\\|^Newsgroups:.*gnus" "gnus-stuff") ("^Subject:.*vm\\|^Xref:.*vm" "vm-stuff") (my-choosing-function "../other-dir/my-stuff") ((equal gnus-newsgroup-name "mail.misc") "mail-stuff"))
We see that this is a list where each element is a list that has two
elements--the match and the file. The match can either be
a string (in which case it is used as a regexp to match on the article
head); it can be a symbol (which will be called as a function with the
group name as a parameter); or it can be a list (which will be
eval
ed). If any of these actions have a non-nil
result,
the file will be used as a default prompt. In addition, the
result of the operation itself will be used if the function or form
called returns a string or a list of strings.
You basically end up with a list of file names that might be used when saving the current article. (All "matches" will be used.) You will then be prompted for what you really want to use as a name, with file name completion over the results from applying this variable.
This variable is ((gnus-article-archive-name))
by default, which
means that Gnus will look at the articles it saves for an
Archive-name
line and use that as a suggestion for the file
name.
Finally, you have the gnus-use-long-file-name
variable. If it is
nil
, all the preceding functions will replace all periods
(`.') in the group names with slashes (`/')---which means that
the functions will generate hierarchies of directories instead of having
all the files in the toplevel directory
(`~/News/alt/andrea-dworkin' instead of
`~/News/alt.andrea-dworkin'.) This variable is t
by default
on most systems. However, for historical reasons, this is nil
on
Xenix and usg-unix-v machines by default.
This function also affects kill and score file names. If this variable
is a list, and the list contains the element not-score
, long file
names will not be used for score files, if it contains the element
not-save
, long file names will not be used for saving, and if it
contains the element not-kill
, long file names will not be used
for kill files.
If you'd like to save articles in a hierarchy that looks something like a spool, you could
(setq gnus-use-long-file-name '(not-save)) ; to get a hierarchy (setq gnus-default-article-save 'gnus-summary-save-in-file) ; no encoding
Then just save with o. You'd then read this hierarchy with
ephemeral nneething
groups---G D in the group buffer, and
the toplevel directory as the argument (`~/News/'). Then just walk
around to the groups/directories with nneething
.
Sometime users post articles (or series of articles) that have been encoded in some way or other. Gnus can decode them for you.
All these functions use the process/prefix convention (see section Process/Prefix) for finding out what articles to work on, with the extension that a "single article" means "a single series". Gnus can find out by itself what articles belong to a series, decode all the articles and unpack/view/save the resulting file(s).
Gnus guesses what articles are in the series according to the following simplish rule: The subjects must be (nearly) identical, except for the last two numbers of the line. (Spaces are largely ignored, however.)
For example: If you choose a subject called `cat.gif (2/3)', Gnus will find all the articles that match the regexp `^cat.gif ([0-9]+/[0-9]+).*$'.
Subjects that are nonstandard, like `cat.gif (2/3) Part 6 of a series', will not be properly recognized by any of the automatic viewing commands, and you have to mark the articles manually with #.
gnus-uu-decode-uu
).
gnus-uu-decode-uu-and-save
).
gnus-uu-decode-uu-view
).
gnus-uu-decode-uu-and-save-view
).
Remember that these all react to the presence of articles marked with
the process mark. If, for instance, you'd like to decode and save an
entire newsgroup, you'd typically do M P a
(gnus-uu-mark-all
) and then X U
(gnus-uu-decode-uu-and-save
).
All this is very much different from how gnus-uu
worked with
GNUS 4.1, where you had explicit keystrokes for everything under
the sun. This version of gnus-uu
generally assumes that you mark
articles in some way (see section Setting Process Marks) and then press
X u.
Note: When trying to decode articles that have names matching
gnus-uu-notify-files
, which is hard-coded to
`[Cc][Ii][Nn][Dd][Yy][0-9]+.\\(gif\\|jpg\\)', gnus-uu
will
automatically post an article on `comp.unix.wizards' saying that
you have just viewed the file in question. This feature can't be turned
off.
gnus-uu-decode-unshar
).
gnus-uu-decode-unshar-and-save
).
gnus-uu-decode-unshar-view
).
gnus-uu-decode-unshar-and-save-view
).
gnus-uu-decode-postscript
).
gnus-uu-decode-postscript-and-save
).
gnus-uu-decode-postscript-view
).
gnus-uu-decode-postscript-and-save-view
).
Adjective, not verb.
Gnus uses rule variables to decide how to view a file. All these variables are on the form
(list '(regexp1 command2) '(regexp2 command2) ...)
gnus-uu-user-view-rules
sox
to convert an `.au' sound file, you could
say something like:
(setq gnus-uu-user-view-rules (list '(\"\\\\.au$\" \"sox %s -t .aiff > /dev/audio\")))
gnus-uu-user-view-rules-end
gnus-uu-user-archive-rules
gnus-uu-grabbed-file-functions
gnus-uu-grab-view
gnus-uu-grab-move
gnus-uu-be-dangerous
nil
, be as conservative as possible. If t
, ignore things
that didn't work, and overwrite existing files. Otherwise, ask each
time.
gnus-uu-ignore-files-by-name
gnus-uu-ignore-files-by-type
gnus-uu
is not a MIME package (yet), so this is slightly
kludgey.
gnus-uu-tmp-dir
gnus-uu
does its work.
gnus-uu-do-not-unpack-archives
nil
means that gnus-uu
won't peek inside archives
looking for files to display.
gnus-uu-view-and-save
nil
means that the user will always be asked to save a file
after viewing it.
gnus-uu-ignore-default-view-rules
nil
means that gnus-uu
will ignore the default viewing
rules.
gnus-uu-ignore-default-archive-rules
nil
means that gnus-uu
will ignore the default archive
unpacking commands.
gnus-uu-kill-carriage-return
nil
means that gnus-uu
will strip all carriage returns
from articles.
gnus-uu-unmark-articles-not-decoded
nil
means that gnus-uu
will mark articles that were
unsuccessfully decoded as unread.
gnus-uu-correct-stripped-uucode
nil
means that gnus-uu
will try to fix
uuencoded files that have had trailing spaces deleted.
gnus-uu-view-with-metamail
nil
means that gnus-uu
will ignore the viewing
commands defined by the rule variables and just fudge a MIME
content type based on the file name. The result will be fed to
metamail
for viewing.
gnus-uu-save-in-digest
nil
means that gnus-uu
, when asked to save without
decoding, will save in digests. If this variable is nil
,
gnus-uu
will just save everything in a file without any
embellishments. The digesting almost conforms to RFC1153--no easy way
to specify any meaningful volume and issue numbers were found, so I
simply dropped them.
gnus-uu-post-include-before-composing
nil
means that gnus-uu
will ask for a file to encode
before you compose the article. If this variable is t
, you can
either include an encoded file with C-c C-i or have one included
for you when you post the article.
gnus-uu-post-length
gnus-uu-post-threaded
nil
means that gnus-uu
will post the encoded file in a
thread. This may not be smart, as no other decoder I have seen are able
to follow threads when collecting uuencoded articles. (Well, I have
seen one package that does that---gnus-uu
, but somehow, I don't
think that counts...) Default is nil
.
gnus-uu-post-separate-description
nil
means that the description will be posted in a separate
article. The first article will typically be numbered (0/x). If this
variable is nil
, the description the user enters will be included
at the beginning of the first article, which will be numbered (1/x).
Default is t
.
After decoding, if the file is some sort of archive, Gnus will attempt to unpack the archive and see if any of the files in the archive can be viewed. For instance, if you have a gzipped tar file `pics.tar.gz' containing the files `pic1.jpg' and `pic2.gif', Gnus will uncompress and de-tar the main file, and then view the two pictures. This unpacking process is recursive, so if the archive contains archives of archives, it'll all be unpacked.
Finally, Gnus will normally insert a pseudo-article for each extracted file into the summary buffer. If you go to these "articles", you will be prompted for a command to run (usually Gnus will make a suggestion), and then the command will be run.
If gnus-view-pseudo-asynchronously
is nil
, Emacs will wait
until the viewing is done before proceeding.
If gnus-view-pseudos
is automatic
, Gnus will not insert
the pseudo-articles into the summary buffer, but view them
immediately. If this variable is not-confirm
, the user won't even
be asked for a confirmation before viewing is done.
If gnus-view-pseudos-separately
is non-nil
, one
pseudo-article will be created for each file to be viewed. If
nil
, all files that use the same viewing command will be given as
a list of parameters to that command.
If gnus-insert-pseudo-articles
is non-nil
, insert
pseudo-articles when decoding. It is t
by default.
So; there you are, reading your pseudo-articles in your virtual newsgroup from the virtual server; and you think: Why isn't anything real anymore? How did we get here?
Reading through this huge manual, you may have quite forgotten that the object of newsreaders are to actually, like, read what people have written. Reading articles. Unfortunately, people are quite bad at writing, so there are tons of functions and variables to make reading these articles easier.
Not only do you want your article buffer to look like fruit salad, but you want it to look like technicolor fruit salad.
gnus-article-highlight
).
gnus-article-highlight-headers
). The
highlighting will be done according to the gnus-header-face-alist
variable, which is a list where each element has the form (regexp
name content). regexp is a regular expression for matching the
header, name is the face used for highlighting the header name and
content is the face for highlighting the header value. The first
match made will be used. Note that regexp shouldn't have `^'
prepended--Gnus will add one.
gnus-article-highlight-citation
).
Some variables to customize the citation highlights:
gnus-cite-parse-max-size
gnus-cite-prefix-regexp
gnus-cite-max-prefix
gnus-cite-face-list
gnus-supercite-regexp
gnus-supercite-secondary-regexp
gnus-cite-minimum-match-count
gnus-cite-attribution-prefix
gnus-cite-attribution-suffix
gnus-cite-attribution-face
gnus-article-highlight-signature
).
Everything after gnus-signature-separator
(see section Article Signature) in an article will be considered a signature and will be
highlighted with gnus-signature-face
, which is italic
by
default.
People commonly add emphasis to words in news articles by writing things
like `_this_' or `*this*'. Gnus can make this look nicer by
running the article through the W e
(gnus-article-emphasize
) command.
How the emphasis is computed is controlled by the
gnus-article-emphasis
variable. This is an alist where the first
element is a regular expression to be matched. The second is a number
that says what regular expression grouping used to find the entire
emphasized word. The third is a number that says what regexp grouping
should be displayed and highlighted. (The text between these two
groupings will be hidden.) The fourth is the face used for
highlighting.
(setq gnus-article-emphasis '(("_\\(\\w+\\)_" 0 1 gnus-emphasis-underline) ("\\*\\(\\w+\\)\\*" 0 1 gnus-emphasis-bold)))
By default, there are seven rules, and they use the following faces:
gnus-emphasis-bold
, gnus-emphasis-italic
,
gnus-emphasis-underline
, gnus-emphasis-bold-italic
,
gnus-emphasis-underline-italic
,
gnus-emphasis-undeline-bold
, and
gnus-emphasis-underline-bold-italic
.
If you want to change these faces, you can either use M-x
customize, or you can use copy-face
. For instance, if you want
to make gnus-emphasis-italic
use a red face instead, you could
say something like:
(copy-face 'red 'gnus-emphasis-italic)
Or rather, hiding certain things in each article. There usually is much too much cruft in most articles.
gnus-article-hide-headers
). See section Hiding Headers.
gnus-article-hide-boring-headers
). See section Hiding Headers.
gnus-article-hide-signature
). See section Article Signature.
gnus-article-hide-pgp
).
gnus-article-hide-pem
).
gnus-article-hide-citation
). Some variables for
customizing the hiding:
gnus-cite-hide-percentage
gnus-cite-hide-absolute
gnus-cited-text-button-line-format
gnus-cited-lines-visible
gnus-article-hide-citation-in-followups
). This isn't very
useful as an interactive command, but might be a handy function to stick
in gnus-article-display-hook
(see section Customizing Articles).
All these "hiding" commands are toggles, but if you give a negative prefix to these commands, they will show what they have previously hidden. If you give a positive prefix, they will always hide.
Also see section Article Highlighting for further variables for citation customization.
We call this "article washing" for a really good reason. Namely, the A key was taken, so we had to use the W key instead.
Washing is defined by us as "changing something from something to something else", but normally results in something looking better. Cleaner, perhaps.
gnus-summary-stop-page-breaking
).
gnus-summary-caesar-message
).
gnus-summary-toggle-header
).
gnus-summary-verbose-header
).
gnus-summary-toggle-mime
).
gnus-article-treat-overstrike
).
gnus-article-fill-cited-article
). If you use this
function in gnus-article-display-hook
, it should be run fairly
late and certainly after any highlighting.
You can give the command a numerical prefix to specify the width to use
when filling.
gnus-article-remove-cr
).
gnus-article-de-quoted-unreadable
).
gnus-article-display-x-face
). The command executed by this
function is given by the gnus-article-x-face-command
variable.
If this variable is a string, this string will be executed in a
sub-shell. If it is a function, this function will be called with the
face as the argument. If the gnus-article-x-face-too-ugly
(which
is a regexp) matches the From
header, the face will not be shown.
The default action under Emacs is to fork off an xv
to view the
face; under XEmacs the default action is to display the face before the
From
header. (It's nicer if XEmacs has been compiled with X-Face
support--that will make display somewhat faster. If there's no native
X-Face support, Gnus will try to convert the X-Face
header using
external programs from the pbmplus
package and friends.) If you
want to have this function in the display hook, it should probably come
last.
gnus-article-add-buttons
).
gnus-article-add-buttons-to-head
).
gnus-article-strip-leading-blank-lines
).
gnus-article-strip-multiple-blank-lines
).
gnus-article-remove-trailing-blank-lines
).
gnus-article-strip-blank-lines
).
gnus-article-strip-leading-space
).
People often include references to other stuff in articles, and it would be nice if Gnus could just fetch whatever it is that people talk about with the minimum of fuzz.
Gnus adds buttons to certain standard references by default: Well-formed URLs, mail addresses and Message-IDs. This is controlled by two variables, one that handles article bodies and one that handles article heads:
gnus-button-alist
(REGEXP BUTTON-PAR USE-P FUNCTION DATA-PAR)
eval
ed, and if the result is non-nil
,
this is considered a match. This is useful if you want extra sifting to
avoid false matches.
("<URL:\\([^\n\r>]*\\)>" 0 t gnus-button-url 1)
gnus-header-button-alist
(HEADER REGEXP BUTTON-PAR USE-P FUNCTION DATA-PAR)header is a regular expression.
gnus-button-url-regexp
gnus-article-button-face
gnus-article-mouse-face
The date is most likely generated in some obscure timezone you've never heard of, so it's quite nice to be able to find out what the time was when the article was sent.
gnus-article-date-ut
).
gnus-article-date-local
).
gnus-article-date-user
). The format is specified by the
gnus-article-time-format
variable, and is a string that's passed
to format-time-string
. See the documentation of that variable
for a list possible format specs.
gnus-article-date-lapsed
).
gnus-article-date-original
). This can
be useful if you normally use some other conversion function and is
worried that it might be doing something totally wrong. Say, claiming
that the article was posted in 1854. Although something like that is
totally impossible. Don't you trust me? *titter*
Each article is divided into two parts--the head and the body. The
body can be divided into a signature part and a text part. The variable
that says what is to be considered a signature is
gnus-signature-separator
. This is normally the standard
`^-- $' as mandated by son-of-RFC 1036. However, many people use
non-standard signature separators, so this variable can also be a list
of regular expressions to be tested, one by one. (Searches are done
from the end of the body towards the beginning.) One likely value is:
(setq gnus-signature-separator '("^-- $" ; The standard "^-- *$" ; A common mangling "^-------*$" ; Many people just use a looong ; line of dashes. Shame! "^ *--------*$" ; Double-shame! "^________*$" ; Underscores are also popular "^========*$")) ; Pervert!
The more permissive you are, the more likely it is that you'll get false positives.
gnus-signature-limit
provides a limit to what is considered a
signature.
nil
, there is no signature in the buffer.
This variable can also be a list where the elements may be of the types listed above.
gnus-summary-print-article
). gnus-ps-print-hook
will be
run just before printing the buffer.
You can have the summary buffer sorted in various ways, even though I can't really see why you'd want that.
gnus-summary-sort-by-number
).
gnus-summary-sort-by-author
).
gnus-summary-sort-by-subject
).
gnus-summary-sort-by-date
).
gnus-summary-sort-by-lines
).
gnus-summary-sort-by-score
).
These functions will work both when you use threading and when you don't use threading. In the latter case, all summary lines will be sorted, line by line. In the former case, sorting will be done on a root-by-root basis, which might not be what you were looking for. To toggle whether to use threading, type T T (see section Thread Commands).
If you'd like to read the parent of the current article, and it is not
displayed in the summary buffer, you might still be able to. That is,
if the current group is fetched by NNTP, the parent hasn't expired
and the References
in the current article are not mangled, you
can just press ^ or A r
(gnus-summary-refer-parent-article
). If everything goes well,
you'll get the parent. If the parent is already displayed in the
summary buffer, point will just move to this article.
If given a positive numerical prefix, fetch that many articles back into the ancestry. If given a negative numerical prefix, fetch just that ancestor. So if you say 3 ^, Gnus will fetch the parent, the grandparent and the grandgrandparent of the current article. If you say -3 ^, Gnus will only fetch the grandgrandparent of the current article.
You can have Gnus fetch all articles mentioned in the References
header of the article by pushing A R
(gnus-summary-refer-references
).
You can also ask the NNTP server for an arbitrary article, no
matter what group it belongs to. M-^
(gnus-summary-refer-article
) will ask you for a
Message-ID
, which is one of those long, hard-to-read thingies
that look something like `<38o6up$6f2@hymir.ifi.uio.no>'. You
have to get it all exactly right. No fuzzy searches, I'm afraid.
The current select method will be used when fetching by
Message-ID
from non-news select method, but you can override this
by giving this command a prefix.
If the group you are reading is located on a backend that does not
support fetching by Message-ID
very well (like nnspool
),
you can set gnus-refer-article-method
to an NNTP method. It
would, perhaps, be best if the NNTP server you consult is the same
as the one that keeps the spool you are reading from updated, but that's
not really necessary.
Most of the mail backends support fetching by Message-ID
, but do
not do a particularly excellent job of it. That is, nnmbox
and
nnbabyl
are able to locate articles from any groups, while
nnml
and nnfolder
are only able to locate articles that
have been posted to the current group. (Anything else would be too time
consuming.) nnmh
does not support this at all.
Different people like to read news using different methods. This being Gnus, we offer a small selection of minor modes for the summary buffers.
Some newsreaders (like nn
and, uhm, nn
) use a two-phased
reading interface. The user first marks the articles she wants to read
from a summary buffer. Then she starts reading the articles with just
an article buffer displayed.
Gnus provides a summary buffer minor mode that allows
this---gnus-pick-mode
. This basically means that a few process
mark commands become one-keystroke commands to allow easy marking, and
it makes one additional command for switching to the summary buffer
available.
Here are the available keystrokes when using pick mode:
gnus-summary-mark-as-processable
). If given a numerical prefix,
go to the article on that line and pick that article. (The line number
is normally displayed on the beginning of the summary pick lines.)
gnus-pick-next-page
). If
at the end of the buffer, start reading the picked articles.
gnus-summary-unmark-as-processable
).
gnus-summary-unmark-all-processable
).
gnus-uu-mark-thread
).
gnus-uu-unmark-thread
).
gnus-uu-mark-region
).
gnus-uu-unmark-region
).
gnus-uu-mark-by-regexp
).
gnus-uu-unmark-by-regexp
).
gnus-uu-mark-buffer
).
gnus-uu-unmark-buffer
).
gnus-pick-start-reading
). If
given a prefix, mark all unpicked articles as read first. If
gnus-pick-display-summary
is non-nil
, the summary buffer
will still be visible when you are reading.
If this sounds like a good idea to you, you could say:
(add-hook 'gnus-summary-mode-hook 'gnus-pick-mode)
gnus-pick-mode-hook
is run in pick minor mode buffers.
If gnus-mark-unpicked-articles-as-read
is non-nil
, mark
all unpicked articles as read. The default is nil
.
The summary line format in pick mode is slightly different than the
standard format. At the beginning of each line the line number is
displayed. The pick mode line format is controlled by the
gnus-summary-pick-line-format
variable (see section Formatting Variables). It accepts the same format specs that
gnus-summary-line-format
does (see section Summary Buffer Lines).
If you spend much time in binary groups, you may grow tired of hitting X u, n, RET all the time. M-x gnus-binary-mode is a minor mode for summary buffers that makes all ordinary Gnus article selection functions uudecode series of articles and display the result instead of just displaying the articles the normal way.
In fact, the only way to see the actual articles if you have turned this
mode on is the g command (gnus-binary-show-article
).
gnus-binary-mode-hook
is called in binary minor mode buffers.
If you don't like the normal Gnus summary display, you might try setting
gnus-use-trees
to t
. This will create (by default) an
additional tree buffer. You can execute all summary mode commands
in the tree buffer.
There are a few variables to customize the tree display, of course:
gnus-tree-mode-hook
gnus-tree-mode-line-format
gnus-selected-tree-face
modeline
.
gnus-tree-line-format
From
header.
gnus-tree-brackets
((?[ . ?]) (?( . ?)) (?{ . ?}))
.
gnus-tree-parent-child-edges
(?- ?\\ ?|)
.
gnus-tree-minimize-window
nil
, Gnus will try to keep the tree
buffer as small as possible to allow more room for the other Gnus
windows. If this variable is a number, the tree buffer will never be
higher than that number. The default is t
. Note that if you
have several windows displayed side-by-side in a frame and the tree
buffer is one of these, minimizing the tree window will also resize all
other windows that are displayed next to it.
gnus-generate-tree-function
gnus-generate-horizontal-tree
and
gnus-generate-vertical-tree
(which is the default).
Here's and example from a horizontal tree buffer:
{***}-(***)-[odd]-[Gun] | \[Jan] | \[odd]-[Eri] | \(***)-[Eri] | \[odd]-[Paa] \[Bjo] \[Gun] \[Gun]-[Jor]
Here's the same thread displayed in a vertical tree buffer:
{***} |--------------------------\-----\-----\ (***) [Bjo] [Gun] [Gun] |--\-----\-----\ | [odd] [Jan] [odd] (***) [Jor] | | |--\ [Gun] [Eri] [Eri] [odd] | [Paa]
Some commands only make sense in mail groups. If these commands are illegal in the current group, they will raise a hell and let you know.
All these commands (except the expiry and edit commands) use the process/prefix convention (see section Process/Prefix).
gnus-summary-expire-articles
).
gnus-summary-expire-articles-now
). This means that all
articles that are eligible for expiry in the current group will
disappear forever into that big `/dev/null' in the sky.
gnus-summary-delete-article
).
gnus-summary-move-article
).
gnus-summary-copy-article
).
gnus-summary-crosspost-article
). This will create a new copy of
the article in the other group, and the Xref headers of the article will
be properly updated.
gnus-summary-import-article
). You will be prompted for a file
name, a From
header and a Subject
header.
gnus-summary-move-article
).
gnus-summary-respool-default-method
will be used as the default
select method when respooling. This variable is nil
by default,
which means that the current group select method will be used instead.
gnus-summary-edit-article
). To finish
editing and make the changes permanent, type C-c C-c
(gnus-summary-edit-article-done).
gnus-summary-respool-query
).
Newsgroups
header in them, but not always. This command
(gnus-summary-article-posted-p
) will try to fetch the current
article from your news server (or rather, from
gnus-refer-article-method
or gnus-select-method
) and will
report back whether it found the article or not. Even if it says that
it didn't find the article, it may have been posted anyway--mail
propagation is much faster than news propagation, and the news copy may
just not have arrived yet.
If you move (or copy) articles regularly, you might wish to have Gnus
suggest where to put the articles. gnus-move-split-methods
is a
variable that uses the same syntax as gnus-split-methods
(see section Saving Articles). You may customize that variable to create
suggestions you find reasonable.
(setq gnus-move-split-methods '(("^From:.*Lars Magne" "nnml:junk") ("^Subject:.*gnus" "nnfolder:important") (".*" "nnml:misc")))
gnus-summary-mode-hook
gnus-summary-generate-hook
gnus-summary-prepare-hook
gnus-summary-ignore-duplicates
Message-ID
,
it has to do something drastic. No articles are allowed to have the
same Message-ID
, but this may happen when reading mail from some
sources. Gnus allows you to customize what happens with this variable.
If it is nil
(which is the default), Gnus will rename the
Message-ID
(for display purposes only) and display the article as
any other article. If this variable is t
, it won't display the
article--it'll be as if it never existed.
gnus-summary-fetch-faq
). Gnus will try to get the
FAQ from gnus-group-faq-directory
, which is usually a directory
on a remote machine. This variable can also be a list of directories.
In that case, giving a prefix to this command will allow you to choose
between the various sites. ange-ftp
probably will be used for
fetching the file.
gnus-summary-describe-group
). If given a prefix, force
rereading the description from the server.
gnus-summary-describe-briefly
).
gnus-info-find-node
).
gnus-summary-search-article-forward
).
gnus-summary-search-article-backward
).
gnus-summary-execute-command
).
gnus-summary-universal-argument
).
gnus-summary-prepare
).
gnus-summary-insert-cached-articles
).
gnus-summary-enter-digest-group
). Gnus will try to
guess what article type is currently displayed unless you give a prefix
to this command, which forces a "digest" interpretation. Basically,
whenever you see a message that is a collection of other messages on
some format, you C-d and read these messages in a more convenient
fashion.
gnus-summary-read-document
). It does this by opening several
nndoc
groups for each document, and then opening an
nnvirtual
group on top of these nndoc
groups. This
command understands the process/prefix convention
(see section Process/Prefix).
gnus-summary-toggle-truncation
). This will probably confuse the
line centering function in the summary buffer, so it's not a good idea
to have truncation switched off while reading articles.
gnus-summary-expand-window
).
If given a prefix, force an article
window configuration.
Exiting from the summary buffer will normally update all info on the group and return you to the group buffer.
gnus-summary-exit
). gnus-summary-prepare-exit-hook
is
called before doing much of the exiting, and calls
gnus-summary-expire-articles
by default.
gnus-summary-exit-hook
is called after finishing the exiting
process. gnus-group-no-more-groups-hook
is run when returning to
group mode having no more (unread) groups.
gnus-summary-exit-no-update
).
gnus-summary-catchup-and-exit
).
gnus-summary-catchup-all-and-exit
).
gnus-summary-catchup-and-goto-next-group
).
gnus-summary-reselect-current-group
). If given a prefix, select
all articles, both read and unread.
gnus-summary-rescan-group
). If given a prefix, select all
articles, both read and unread.
gnus-summary-next-group
).
gnus-summary-prev-group
).
gnus-summary-save-newsrc
). If
given a prefix, also save the `.newsrc' file(s). Using this
command will make exit without updating (the Q command) worthless.
gnus-exit-group-hook
is called when you exit the current
group.
If you're in the habit of exiting groups, and then changing your mind
about it, you might set gnus-kill-summary-on-exit
to nil
.
If you do that, Gnus won't kill the summary buffer when you exit it.
(Quelle surprise!) Instead it will change the name of the buffer to
something like `*Dead Summary ... *' and install a minor mode
called gnus-dead-summary-mode
. Now, if you switch back to this
buffer, you'll find that all keys are mapped to a function called
gnus-summary-wake-up-the-dead
. So tapping any keys in a dead
summary buffer will result in a live, normal summary buffer.
There will never be more than one dead summary buffer at any one time.
The data on the current group will be updated (which articles you have
read, which articles you have replied to, etc.) when you exit the
summary buffer. If the gnus-use-cross-reference
variable is
t
(which is the default), articles that are cross-referenced to
this group and are marked as read, will also be marked as read in the
other subscribed groups they were cross-posted to. If this variable is
neither nil
nor t
, the article will be marked as read in
both subscribed and unsubscribed groups (see section Crosspost Handling).
Marking cross-posted articles as read ensures that you'll never have to read the same article more than once. Unless, of course, somebody has posted it to several groups separately. Posting the same article to several groups (not cross-posting) is called spamming, and you are by law required to send nasty-grams to anyone who perpetrates such a heinous crime. You may want to try NoCeM handling to filter out spam (see section NoCeM).
Remember: Cross-posting is kinda ok, but posting the same article
separately to several groups is not. Massive cross-posting (aka.
velveeta) is to be avoided at all costs, and you can even use the
gnus-summary-mail-crosspost-complaint
command to complain about
excessive crossposting (see section Summary Mail Commands).
One thing that may cause Gnus to not do the cross-posting thing
correctly is if you use an NNTP server that supports XOVER
(which is very nice, because it speeds things up considerably) which
does not include the Xref
header in its NOV lines. This is
Evil, but all too common, alas, alack. Gnus tries to Do The Right Thing
even with XOVER by registering the Xref
lines of all
articles you actually read, but if you kill the articles, or just mark
them as read without reading them, Gnus will not get a chance to snoop
the Xref
lines out of these articles, and will be unable to use
the cross reference mechanism.
To check whether your NNTP server includes the Xref
header
in its overview files, try `telnet your.nntp.server nntp',
`MODE READER' on inn
servers, and then say `LIST
overview.fmt'. This may not work, but if it does, and the last line you
get does not read `Xref:full', then you should shout and whine at
your news admin until she includes the Xref
header in the
overview files.
If you want Gnus to get the Xref
s right all the time, you have to
set gnus-nov-is-evil
to t
, which slows things down
considerably.
C'est la vie.
For an alternative approach, see section Duplicate Suppression.
By default, Gnus tries to make sure that you don't have to read the same article more than once by utilizing the crossposting mechanism (see section Crosspost Handling). However, that simple and efficient approach may not work satisfactorily for some users for various reasons.
Xref
header. This
is evil and not very common.
Xref
header in the
`.overview' data bases. This is evil and all too common, alas.
I'm sure there are other situations that Xref
handling fails as
well, but these four are the most common situations.
If, and only if, Xref
handling fails for you, then you may
consider switching on duplicate suppression. If you do so, Gnus
will remember the Message-ID
s of all articles you have read or
otherwise marked as read, and then, as if by magic, mark them as read
all subsequent times you see them--in all groups. Using this
mechanism is quite likely to be somewhat inefficient, but not overly
so. It's certainly preferable to reading the same articles more than
once.
Duplicate suppression is not a very subtle instrument. It's more like a sledge hammer than anything else. It works in a very simple fashion--if you have marked an article as read, it adds this Message-ID to a cache. The next time it sees this Message-ID, it will mark the article as read the the `M' mark. It doesn't care what group it saw the article in.
gnus-suppress-duplicates
nil
, suppress duplicates.
gnus-save-duplicate-list
nil
, save the list of duplicates to a file. This will
make startup and shutdown take longer, so the default is nil
.
However, this means that only duplicate articles that is read in a
single Gnus session are suppressed.
gnus-duplicate-list-length
Message-ID
s to keep in the duplicate
suppression list. The default is 10000.
gnus-duplicate-file
If you have a tendency to stop and start Gnus often, setting
gnus-save-duplicate-list
to t
is probably a good idea. If
you leave Gnus running for weeks on end, you may have it nil
. On
the other hand, saving the list makes startup and shutdown much slower,
so that means that if you stop and start Gnus often, you should set
gnus-save-duplicate-list
to nil
. Uhm. I'll leave this up
to you to figure out, I think.
Go to the first, previous, next, last section, table of contents.