Sorting The Summary Buffer Article Caching
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 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 it can without bound. If it is
nil
, no pre-fetching will be done.
There are probably some articles that you don't want to pre-fetch---read
articles, for instance. The gnus-async-prefetch-article-p
variable controls whether an article is to be pre-fetched. 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 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 preferably be short and sweet to avoid slowing down Gnus too much. It's 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
|
Remove articles when they are read. |
exit
|
Remove articles when exiting the group. |
The default value is (read exit)
.