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
t. The rest should
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 back end will pre-fetch
the next 30 articles. If this variable is
t, the back end 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
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
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.
After an article has been prefetched, this
gnus-async-post-fetch-function will be called. The buffer will
be narrowed to the region of the article that was fetched. A useful
value would be
gnus-html-prefetch-images, which will prefetch
and store images referenced in the article, so that you don't have to
wait for them to be fetched when you read the article. This is useful
for HTML messages that have external images.
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:
The default value is