Next: , Previous: , Up: Summary Buffer   [Contents][Index]

4.23 Finding the Parent

^

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 great-grandparent of the current article. If you say -3 ^, Gnus will only fetch the great-grandparent of the current article.

A R (Summary)

Fetch all articles mentioned in the References header of the article (gnus-summary-refer-references).

A T (Summary)

Display the full thread where the current article appears (gnus-summary-refer-thread). By default this command looks for articles only in the current group. If the group belongs to a backend that has an associated search engine, articles are found by searching. In other cases each header in the current group must be fetched and examined, so it usually takes a while. If you do it often, you may consider setting gnus-fetch-old-headers to invisible (see Filling In Threads). This won’t have any visible effects normally, but it’ll make this command work a whole lot faster. Of course, it’ll make group entry somewhat slow.

If gnus-refer-thread-use-search is nil (the default) then thread-referral only looks for articles in the current group. If this variable is t the server to which the current group belongs is searched (provided that searching is available for the server’s backend). If this variable is a list of servers, each server in the list is searched.

The gnus-refer-thread-limit variable says how many old (i.e., articles before the first displayed in the current group) headers to fetch when referring a thread. The default is 500. If t, all the available headers will be fetched. This variable can be overridden by giving the A T command a numerical prefix.

gnus-summary-refer-thread tries to add any articles it finds to the current summary buffer. (When gnus-refer-thread-use-search is true and the initial referral starts from a summary buffer for a non-virtual group this may not be possible. In this case a new summary buffer is created holding a virtual group with the result of the thread search.) If gnus-refer-thread-limit-to-thread is non-nil then the summary buffer will be limited to articles in the thread.

M-^ (Summary)

You can also ask Gnus 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.

Gnus looks for the Message-ID in the headers that have already been fetched, but also tries all the select methods specified by gnus-refer-article-method if it is not found.

If the group you are reading is located on a back end 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 one updating the spool you are reading from, but that’s not really necessary.

It can also be a list of select methods, as well as the special symbol current, which means to use the current select method. If it is a list, Gnus will try all the methods in the list until it finds a match.

Here’s an example setting that will first try the current method, and then ask Google if that fails:

(setq gnus-refer-article-method
      '(current
        (nnweb "google" (nnweb-type google))))

Most of the mail back ends support fetching by Message-ID, but do not do a particularly excellent job at it. That is, nnmbox, nnbabyl, nnmaildir, nnml, are able to locate articles from any groups, while nnfolder, and nnimap are only able to locate articles that have been posted to the current group. nnmh does not support this at all.

Fortunately, the special nnregistry back end is able to locate articles in any groups, regardless of their back end (see fetching by Message-ID using the registry).

Next: Alternative Approaches, Previous: Summary Sorting, Up: Summary Buffer   [Contents][Index]