4.11 Asynchronous Article Fetching

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

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:

read

Remove articles when they are read.

exit

Remove articles when exiting the group.

The default value is (read exit).