Go to the first, previous, next, last section, table of contents.

# Appendices

- History: How Gnus got where it is today.
- Terminology: We use really difficult, like, words here.
- Customization: Tailoring Gnus to your needs.
- Troubleshooting: What you might try if things do not work.
- A Programmers Guide to Gnus: Rilly, rilly technical stuff.
- Emacs for Heathens: A short introduction to Emacsian terms.
- Frequently Asked Questions: A question-and-answer session.

## History

GNUS was written by Masanobu UMEDA. When autumn crept up in '94, Lars Magne Ingebrigtsen grew bored and decided to rewrite Gnus.

If you want to investigate the person responsible for this outrage, you can point your (feh!) web browser to ``http://www.ifi.uio.no/~larsi/'`. This is also the primary distribution point for the new and spiffy versions of Gnus, and is known as The Site That Destroys Newsrcs And Drives People Mad.

During the first extended alpha period of development, the new Gnus was called "(ding) Gnus". (ding), is, of course, short for ding is not Gnus, which is a total and utter lie, but who cares? (Besides, the "Gnus" in this abbreviation should probably be pronounced "news" as UMEDA intended, which makes it a more appropriate name, don't you think?)

In any case, after spending all that energy on coming up with a new and spunky name, we decided that the name was too spunky, so we renamed it back again to "Gnus". But in mixed case. "Gnus" vs. "GNUS". New vs. old.

The first "proper" release of Gnus 5 was done in November 1995 when it was included in the Emacs 19.30 distribution.

In May 1996 the next Gnus generation (aka. "September Gnus") was released under the name "Gnus 5.2".

- Why?: What's the point of Gnus?
- Compatibility: Just how compatible is Gnus with GNUS?
- Conformity: Gnus tries to conform to all standards.
- Emacsen: Gnus can be run on a few modern Emacsen.
- Contributors: Oodles of people.
- New Features: Pointers to some of the new stuff in Gnus.
- Newest Features: Features so new that they haven't been written yet.

### Why?

What's the point of Gnus?

I want to provide a "rad", "happening", "way cool" and "hep" newsreader, that lets you do anything you can think of. That was my original motivation, but while working on Gnus, it has become clear to me that this generation of newsreaders really belong in the stone age. Newsreaders haven't developed much since the infancy of the net. If the volume continues to rise with the current rate of increase, all current newsreaders will be pretty much useless. How do you deal with newsgroups that have thousands of new articles each day? How do you keep track of millions of people who post?

Gnus offers no real solutions to these questions, but I would very much like to see Gnus being used as a testing ground for new methods of reading and fetching news. Expanding on UMEDA-san's wise decision to separate the newsreader from the backends, Gnus now offers a simple interface for anybody who wants to write new backends for fetching mail and news from different sources. I have added hooks for customizations everywhere I could imagine useful. By doing so, I'm inviting every one of you to explore and invent.

May Gnus never be complete. `C-u 100 M-x hail-emacs`.

### Compatibility

Gnus was designed to be fully compatible with GNUS. Almost all key bindings have been kept. More key bindings have been added, of course, but only in one or two obscure cases have old bindings been changed.

Our motto is:

> In a cloud bones of steel.

All commands have kept their names. Some internal functions have changed their names.

The `gnus-uu` package has changed drastically. see section Decoding Articles.

One major compatibility question is the presence of several summary buffers. All variables that are relevant while reading a group are buffer-local to the summary buffer they belong in. Although many important variables have their values copied into their global counterparts whenever a command is executed in the summary buffer, this change might lead to incorrect values being used unless you are careful.

All code that relies on knowledge of GNUS internals will probably fail. To take two examples: Sorting `gnus-newsrc-alist` (or changing it in any way, as a matter of fact) is strictly verboten. Gnus maintains a hash table that points to the entries in this alist (which speeds up many functions), and changing the alist directly will lead to peculiar results.

Old hilit19 code does not work at all. In fact, you should probably remove all hilit code from all Gnus hooks (`gnus-group-prepare-hook` and `gnus-summary-prepare-hook`). Gnus provides various integrated functions for highlighting. These are faster and more accurate. To make life easier for everybody, Gnus will by default remove all hilit calls from all hilit hooks. Uncleanliness! Away!

Packages like `expire-kill` will no longer work. As a matter of fact, you should probably remove all old GNUS packages (and other code) when you start using Gnus. More likely than not, Gnus already does what you have written code to make GNUS do. (Snicker.)

Even though old methods of doing things are still supported, only the new methods are documented in this manual. If you detect a new method of doing something while reading this manual, that does not mean you have to stop doing it the old way.

Gnus understands all GNUS startup files.

Overall, a casual user who hasn't written much code that depends on GNUS internals should suffer no problems. If problems occur, please let me know by issuing that magic command `M-x gnus-bug`.

### Conformity

No rebels without a clue here, ma'am. We conform to all standards known to (wo)man. Except for those standards and/or conventions we disagree with, of course.

RFC 822
  There are no known breaches of this standard.
RFC 1036
  There are no known breaches of this standard, either.
Usenet Seal of Approval
  Gnus hasn't been formally through the Seal process, but I have read through the Seal text and I think Gnus would pass.
Son-of-RFC 1036
  We do have some breaches to this one.
  MIME
    Gnus does no MIME handling, and this standard-to-be seems to think that MIME is the bees' knees, so we have major breakage here.
  X-Newsreader
    This is considered to be a "vanity header", while I consider it to be consumer information. After seeing so many badly formatted articles coming from `tin` and `Netscape` I know not to use either of those for posting articles. I would not have known that if it wasn't for the `X-Newsreader` header.
  References
    Gnus does line breaking on this header. I infer from RFC1036 that being conservative in what you output is not creating 5000-character lines, so it seems like a good idea to me. However, this standard-to-be says that whitespace in the `References` header is to be preserved, so... It doesn't matter one way or the other to Gnus, so if somebody tells me what The Way is, I'll change it. Or not.

If you ever notice Gnus acting non-compliantly with regards to the texts mentioned above, don't hesitate to drop a note to Gnus Towers and let us know.

### Emacsen

Gnus should work on :

- Emacs 19.30 and up.
- XEmacs 19.13 and up.
- Mule versions based on Emacs 19.30 and up.

Gnus will absolutely not work on any Emacsen older than that. Not reliably, at least.

There are some vague differences between Gnus on the various platforms:

- The mouse-face on Gnus lines under Emacs and Mule is delimited to certain parts of the lines while they cover the entire line under XEmacs.
- The same with current-article marking--XEmacs puts an underline under the entire summary line while Emacs and Mule are nicer and kinder.
- XEmacs features more graphics--a logo and a toolbar.
- Citation highlighting us better under Emacs and Mule than under XEmacs.
- Emacs 19.26-19.28 have tangible hidden headers, which can be a bit confusing.

### Contributors

The new Gnus version couldn't have been done without the help of all the people on the (ding) mailing list. Every day for over a year I have gotten billions of nice bug reports from them, filling me with joy, every single one of them. Smooches. The people on the list have been tried beyond endurance, what with my "oh, that's a neat idea <type type>, yup, I'll release it right away <ship off> no wait, that doesn't work at all <type type>, yup, I'll ship that one off right away <ship off> no, wait, that absolutely does not work" policy for releases. Micro$oft--bah. Amateurs. I'm much worse. (Or is that "worser"? "much worser"? "worsest"?)

I would like to take this opportunity to thank the Academy for... oops, wrong show.

- Masanobu UMEDA The writer of the original GNUS.
- Per Abrahamsen Custom, scoring, highlighting and SOUP code (as well as numerous other things).
- Luis Fernandes Design and graphics.
- Wes Hardaker ``gnus-picon.el'` and the manual section on picons (see section Picons).
- Brad Miller ``gnus-gl.el'` and the GroupLens manual section (see section GroupLens).
- Sudish Joseph Innumerable bug fixes.
- Ilja Weis ``gnus-topic.el'`.
- Steven L. Baur Lots and lots of bugs detections and fixes.
- Vladimir Alexiev The refcard and reference booklets.
- Felix Lee & JWZ I stole some pieces from the XGnus distribution by Felix Lee and JWZ.
- Scott Byer ``nnfolder.el'` enhancements & rewrite.
- Peter Mutsaers Orphan article scoring code.
- Ken Raeburn POP mail support.
- Hallvard B Furuseth Various bits and pieces, especially dealing with .newsrc files.
- Brian Edmonds ``gnus-bbdb.el'`.
- Ricardo Nassif and Mark Borges Proof-reading.
- Kevin Davidson Came up with the name ding, so blame him.

Peter Arius, Stainless Steel Rat, Ulrik Dickow, Jack Vinson, Daniel Quinlan, Frank D. Cringle, Geoffrey T. Dairiki, Fabrice Popineau and Andrew Eskilsson have all contributed code and suggestions.

### New Features

- The look of all buffers can be changed by setting format-like variables (see section Group Buffer Format and see section Summary Buffer Format).
- Local spool and several NNTP servers can be used at once (see section Select Methods).
- You can combine groups into virtual groups (see section Virtual Groups).
- You can read a number of different mail formats (see section Getting Mail). All the mail backends implement a convenient mail expiry scheme (see section Expiring Mail).
- Gnus can use various strategies for gathering threads that have lost their roots (thereby gathering loose sub-threads into one thread) or it can go back and retrieve enough headers to build a complete thread (see section Customizing Threading).
- Killed groups can be displayed in the group buffer, and you can read them as well (see section Listing Groups).
- Gnus can do partial group updates--you do not have to retrieve the entire active file just to check for new articles in a few groups (see section The Active File).
- Gnus implements a sliding scale of subscribedness to groups (see section Group Levels).
- You can score articles according to any number of criteria (see section Scoring). You can even get Gnus to find out how to score articles for you (see section Adaptive Scoring).
- Gnus maintains a dribble buffer that is auto-saved the normal Emacs manner, so it should be difficult to lose much data on what you have read if your machine should go down (see section Auto Save).
- Gnus now has its own startup file (``.gnus'`) to avoid cluttering up the ``.emacs'` file.
- You can set the process mark on both groups and articles and perform operations on all the marked items (see section Process/Prefix).
- You can grep through a subset of groups and create a group from the results (see section Kibozed Groups).
- You can list subsets of groups according to, well, anything (see section Listing Groups).
- You can browse foreign servers and subscribe to groups from those servers (see section Browse Foreign Server).
- Gnus can fetch articles asynchronously on a second connection to the server (see section Asynchronous Article Fetching).
- You can cache articles locally (see section Article Caching).
- The uudecode functions have been expanded and generalized (see section Decoding Articles).
- You can still post uuencoded articles, which was a little-known feature of GNUS' past (see section Uuencoding and Posting).
- Fetching parents (and other articles) now actually works without glitches (see section Finding the Parent).
- Gnus can fetch FAQs and group descriptions (see section Group Information).
- Digests (and other files) can be used as the basis for groups (see section Document Groups).
- Articles can be highlighted and customized (see section Customizing Articles).
- URLs and other external references can be buttonized (see section Article Buttons).
- You can do lots of strange stuff with the Gnus window & frame configuration (see section Windows Configuration).
- You can click on buttons instead of using the keyboard (see section Buttons).
- Gnus can use NoCeM files to weed out spam (see section NoCeM).

This is, of course, just a short overview of the most important new features. No, really. There are tons more. Yes, we have feeping creaturism in full effect, but nothing too gratuitous, I would hope.

### Newest Features

Also known as the todo list. Sure to be implemented before the next millennium.

Be afraid. Be very afraid.

- Native MIME support is something that should be done.
- A better and simpler method for specifying mail composing methods.
- Allow posting through mail-to-news gateways.
- Really do unbinhexing.

And much, much, much more. There is more to come than has already been implemented. (But that's always true, isn't it?)

`<URL:http://www.ifi.uio.no/~larsi/sgnus/todo>` is where the actual up-to-the-second todo list is located, so if you're really curious, you could point your Web browser over that-a-way.

## Terminology

news
  This is what you are supposed to use this thing for--reading news. News is generally fetched from a nearby NNTP server, and is generally publicly available to everybody. If you post news, the entire world is likely to read just what you have written, and they'll all snigger mischievously. Behind your back.
mail
  Everything that's delivered to you personally is mail. Some news/mail readers (like Gnus) blur the distinction between mail and news, but there is a difference. Mail is private. News is public. Mailing is not posting, and replying is not following up.
reply
  Send a mail to the person who has written what you are reading.
follow up
  Post an article to the current newsgroup responding to the article you are reading.
backend
  Gnus gets fed articles from a number of backends, both news and mail backends. Gnus does not handle the underlying media, so to speak--this is all done by the backends.
native
  Gnus will always use one method (and backend) as the native, or default, way of getting news.
foreign
  You can also have any number of foreign groups active at the same time. These are groups that use different backends for getting news.
secondary
  Secondary backends are somewhere half-way between being native and being foreign, but they mostly act like they are native.
article
  A nessage that has been posted as news.
mail message
  A message that has been mailed.
message
  A mail message or news article
head
  The top part of a message, where administrative information (etc.) is put.
body
  The rest of an article. Everything that is not in the head is in the body.
header
  A line from the head of an article.
headers
  A collection of such lines, or a collection of heads. Or even a collection of NOV lines.
NOV
  When Gnus enters a group, it asks the backend for the headers of all unread articles in the group. Most servers support the News OverView format, which is more compact and much faster to read and parse than the normal HEAD format.
level
  Each group is subscribed at some level or other (1-9). The ones that have a lower level are "more" subscribed than the groups with a higher level. In fact, groups on levels 1-5 are considered subscribed; 6-7 are unsubscribed; 8 are zombies; and 9 are killed. Commands for listing groups and scanning for new articles will all use the numeric prefix as working level.
killed groups
  No information on killed groups is stored or updated, which makes killed groups much easier to handle than subscribed groups.
zombie groups
  Just like killed groups, only slightly less dead.
active file
  The news server has to keep track of what articles it carries, and what groups exist. All this information in stored in the active file, which is rather large, as you might surmise.
bogus groups
  A group that exists in the ``.newsrc'` file, but isn't known to the server (i. e., it isn't in the active file), is a bogus group. This means that the group probably doesn't exist (any more).
server
  A machine than one can connect to and get news (or mail) from.
select method
  A structure that specifies the backend, the server and the virtual server parameters.
virtual server
  A named select method. Since a select methods defines all there is to know about connecting to a (physical) server, taking the who things as a whole is a virtual server.

## Customization

All variables are properly documented elsewhere in this manual. This section is designed to give general pointers on how to customize Gnus for some quite common situations.

- Slow/Expensive Connection: You run a local Emacs and get the news elsewhere.
- Slow Terminal Connection: You run a remote Emacs.
- Little Disk Space: You feel that having large setup files is icky.
- Slow Machine: You feel like buying a faster machine.

### Slow/Expensive NNTP Connection

If you run Emacs on a machine locally, and get your news from a machine over some very thin strings, you want to cut down on the amount of data Gnus has to get from the NNTP server.

`gnus-read-active-file`
  Set this to `nil`, which will inhibit Gnus from requesting the entire active file from the server. This file is often v. large. You also have to set `gnus-check-new-news` and `gnus-check-bogus-newsgroups` to `nil` to make sure that Gnus doesn't suddenly decide to fetch the active file anyway.
`gnus-nov-is-evil`
  This one has to be `nil`. If not, grabbing article headers from the NNTP server will not be very fast. Not all NNTP servers support XOVER; Gnus will detect this by itself.

### Slow Terminal Connection

Let's say you use your home computer for dialing up the system that runs Emacs and Gnus. If your modem is slow, you want to reduce the amount of data that is sent over the wires as much as possible.

`gnus-auto-center-summary`
  Set this to `nil` to inhibit Gnus from re-centering the summary buffer all the time. If it is `vertical`, do only vertical re-centering. If it is neither `nil` nor `vertical`, do both horizontal and vertical recentering.
`gnus-visible-headers`
  Cut down on the headers that are included in the articles to the minimum. You can, in fact, make do without them altogether--most of the useful data is in the summary buffer, anyway. Set this variable to ``^NEVVVVER'` or ``From:'`, or whatever you feel you need.
`gnus-article-display-hook`
  Set this hook to all the available hiding commands:

      (setq gnus-article-display-hook
            '(gnus-article-hide-headers gnus-article-hide-signature
              gnus-article-hide-citation))

`gnus-use-full-window`
  By setting this to `nil`, you can make all the windows smaller. While this doesn't really cut down much generally, it means that you have to see smaller portions of articles before deciding that you didn't want to read them anyway.
`gnus-thread-hide-subtree`
  If this is non-`nil`, all threads in the summary buffer will be hidden initially.
`gnus-updated-mode-lines`
  If this is `nil`, Gnus will not put information in the buffer mode lines, which might save some time.

### Little Disk Space

The startup files can get rather large, so you may want to cut their sizes a bit if you are running out of space.

`gnus-save-newsrc-file`
  If this is `nil`, Gnus will never save ``.newsrc'`---it will only save ``.newsrc.eld'`. This means that you will not be able to use any other newsreaders than Gnus. This variable is `t` by default.
`gnus-save-killed-list`
  If this is `nil`, Gnus will not save the list of dead groups. You should also set `gnus-check-new-newsgroups` to `ask-server` and `gnus-check-bogus-newsgroups` to `nil` if you set this variable to `nil`. This variable is `t` by default.

### Slow Machine

If you have a slow machine, or are just really impatient, there are a few things you can do to make Gnus run faster.

Set`gnus-check-new-newsgroups` and `gnus-check-bogus-newsgroups` to `nil` to make startup faster.

Set `gnus-show-threads`, `gnus-use-cross-reference` and `gnus-nov-is-evil` to `nil` to make entering and exiting the summary buffer faster.

Set `gnus-article-display-hook` to `nil` to make article processing a bit faster.

## Troubleshooting

Gnus works so well straight out of the box--I can't imagine any problems, really.

Ahem.

1. Make sure your computer is switched on.
2. Make sure that you really load the current Gnus version. If you have been running GNUS, you need to exit Emacs and start it up again before Gnus will work.
3. Try doing an `M-x gnus-version`. If you get something that looks like ``Gnus v5.46; nntp 4.0'` you have the right files loaded. If, on the other hand, you get something like ``NNTP 3.x'` or ``nntp flee'`, you have some old ``.el'` files lying around. Delete these.
4. Read the help group (`G h` in the group buffer) for a FAQ and a how-to.

If all else fails, report the problem as a bug.

If you find a bug in Gnus, you can report it with the `M-x gnus-bug` command. `M-x set-variable RET debug-on-error RET t RET`, and send me the backtrace. I will fix bugs, but I can only fix them if you send me a precise description as to how to reproduce the bug.

You really can never be too detailed in a bug report. Always use the `M-x gnus-bug` command when you make bug reports, even if it creates a 10Kb mail each time you use it, and even if you have sent me your environment 500 times before. I don't care. I want the full info each time.

It is also important to remember that I have no memory whatsoever. If you send a bug report, and I send you a reply, and then you send back just "No, it's not! Moron!", I will have no idea what you are insulting me about. Always over-explain everything. It's much easier for all of us--if I don't have all the information I need, I will just mail you and ask for more info, and everything takes more time.

If the problem you're seeing is very visual, and you can't quite explain it, copy the Emacs window to a file (with `xwd`, for instance), put it somewhere it can be reached, and include the URL of the picture in the bug report.a

If you just need help, you are better off asking on ``gnu.emacs.gnus'`. I'm not very helpful.

You can also ask on the ding mailing list---``ding@ifi.uio.no'`. Write to ``ding-request@ifi.uio.no'` to subscribe.

## A Programmer's Guide to Gnus

It is my hope that other people will figure out smart stuff that Gnus can do, and that other people will write those smart things as well. To facilitate that I thought it would be a good idea to describe the inner workings of Gnus. And some of the not-so-inner workings, while I'm at it.

You can never expect the internals of a program not to change, but I will be defining (in some details) the interface between Gnus and its backends (this is written in stone), the format of the score files (ditto), data structures (some are less likely to change than others) and general method of operations.

- Backend Interface: How Gnus communicates with the servers.
- Score File Syntax: A BNF definition of the score file standard.
- Headers: How Gnus stores headers internally.
- Ranges: A handy format for storing mucho numbers.
- Group Info: The group info format.
- Emacs/XEmacs Code: Gnus can be run under all modern Emacsen.
- Various File Formats: Formats of files that Gnus use.

### Backend Interface

Gnus doesn't know anything about NNTP, spools, mail or virtual groups. It only knows how to talk to virtual servers. A virtual server is a backend and some backend variables. As examples of the first, we have `nntp`, `nnspool` and `nnmbox`. As examples of the latter we have `nntp-port-number` and `nnmbox-directory`.

When Gnus asks for information from a backend--say `nntp`---on something, it will normally include a virtual server name in the function parameters. (If not, the backend should use the "current" virtual server.) For instance, `nntp-request-list` takes a virtual server as its only (optional) parameter. If this virtual server hasn't been opened, the function should fail.

Note that a virtual server name has no relation to some physical server name. Take this example:

    (nntp "odd-one"
          (nntp-address "ifi.uio.no")
          (nntp-port-number 4324))

Here the virtual server name is ``odd-one'` while the name of the physical server is ``ifi.uio.no'`.

The backends should be able to switch between several virtual servers. The standard backends implement this by keeping an alist of virtual server environments that it pulls down/pushes up when needed.

There are two groups of interface functions: required functions, which must be present, and optional functions, which Gnus will always check whether are present before attempting to call.

All these functions are expected to return data in the buffer `nntp-server-buffer` (`` *nntpd*'`), which is somewhat unfortunately named, but we'll have to live with it. When I talk about "resulting data", I always refer to the data in that buffer. When I talk about "return value", I talk about the function value returned by the function call.

Some backends could be said to be server-forming backends, and some might be said to not be. The latter are backends that generally only operate on one group at a time, and have no concept of "server" -- they have a group, and they deliver info on that group and nothing more.

In the examples and definitions I will refer to the imaginary backend `nnchoke`.

- Required Backend Functions: Functions that must be implemented.
- Optional Backend Functions: Functions that need not be implemented.
- Writing New Backends: Extending old backends.

#### Required Backend Functions

`(nnchoke-retrieve-headers ARTICLES &optional GROUP SERVER FETCH-OLD)`
  articles is either a range of article numbers or a list of `Message-ID`s. Current backends do not fully support either--only sequences (lists) of article numbers, and most backends do not support retrieval of `Message-ID`s. But they should try for both. The result data should either be HEADs or NOV lines, and the result value should either be `headers` or `nov` to reflect this. This might later be expanded to `various`, which will be a mixture of HEADs and NOV lines, but this is currently not supported by Gnus. If fetch-old is non-`nil` it says to try to fetch "extra headers, in some meaning of the word. This is generally done by fetching (at most) fetch-old extra headers less than the smallest article number in `articles`, and fill in the gaps as well. The presence of this parameter can be ignored if the backend finds it cumbersome to follow the request. If this is non-`nil` and not a number, do maximum fetches. Here's an example HEAD:

      221 1056 Article retrieved.
      Path: ifi.uio.no!sturles
      From: sturles@ifi.uio.no (Sturle Sunde)
      Newsgroups: ifi.discussion
      Subject: Re: Something very droll
      Date: 27 Oct 1994 14:02:57 +0100
      Organization: Dept. of Informatics, University of Oslo, Norway
      Lines: 26
      Message-ID: <38o8e1$a0o@holmenkollen.ifi.uio.no>
      References: <38jdmq$4qu@visbur.ifi.uio.no>
      NNTP-Posting-Host: holmenkollen.ifi.uio.no
      .

  So a `headers` return value would imply that there's a number of these in the data buffer. Here's a BNF definition of such a buffer:

      headers        = *head
      head           = error / valid-head
      error-message  = [ "4" / "5" ] 2number " " <error message> eol
      valid-head     = valid-message *header "." eol
      valid-message  = "221 " <number> " Article retrieved." eol
      header         = <text> eol

  If the return value is `nov`, the data buffer should contain network overview database lines. These are basically fields separated by tabs.

      nov-buffer = *nov-line
      nov-line   = 8*9 [ field <TAB> ] eol
      field      = <text except TAB>

  For a closer explanation what should be in those fields, see section Headers.
`(nnchoke-open-server SERVER &optional DEFINITIONS)`
  server is here the virtual server name. definitions is a list of `(VARIABLE VALUE)` pairs that defines this virtual server. If the server can't be opened, no error should be signaled. The backend may then choose to refuse further attempts at connecting to this server. In fact, it should do so. If the server is opened already, this function should return a non-`nil` value. There should be no data returned.
`(nnchoke-close-server &optional SERVER)`
  Close connection to server and free all resources connected to it. Return `nil` if the server couldn't be closed for some reason. There should be no data returned.
`(nnchoke-request-close)`
  Close connection to all servers and free all resources that the backend have reserved. All buffers that have been created by that backend should be killed. (Not the `nntp-server-buffer`, though.) This function is generally only called when Gnus is shutting down. There should be no data returned.
`(nnchoke-server-opened &optional SERVER)`
  If server is the current virtual server, and the connection to the physical server is alive, then this function should return a non-`nil` vlue. This function should under no circumstances attempt to reconnect to a server that is has lost connection to. There should be no data returned.
`(nnchoke-status-message &optional SERVER)`
  This function should return the last error message from server. There should be no data returned.
`(nnchoke-request-article ARTICLE &optional GROUP SERVER TO-BUFFER)`
  The result data from this function should be the article specified by article. This might either be a `Message-ID` or a number. It is optional whether to implement retrieval by `Message-ID`, but it would be nice if that were possible. If to-buffer is non-`nil`, the result data should be returned in this buffer instead of the normal data buffer. This is to make it possible to avoid copying large amounts of data from one buffer to another, and Gnus mainly request articles to be inserted directly into its article buffer. If it is at all possible, this function should return a cons cell where the car is the group name the article was fetched from, and the cdr is the article number. This will enable Gnus to find out what the real group and article numbers are when fetching articles by `Message-ID`. If this isn't possible, `t` should be returned on successful article retrievement.
`(nnchoke-open-group GROUP &optional SERVER)`
  Make group the current group. There should be no data returned by this function.
`(nnchoke-request-group GROUP &optional SERVER)`
  Get data on group. This function also has the side effect of making group the current group. Here's an example of some result data and a definition of the same:

      211 56 1000 1059 ifi.discussion

  The first number is the status, which should be `211`. Next is the total number of articles in the group, the lowest article number, the highest article number, and finally the group name. Note that the total number of articles may be less than one might think while just considering the highest and lowest article numbers, but some articles may have been canceled. Gnus just discards the total-number, so whether one should take the bother to generate it properly (if that is a problem) is left as an exercise to the reader.

      group-status = [ error / info ] eol
      error        = [ "4" / "5" ] 2<number> " " <Error message>
      info         = "211 " 3* [ <number> " " ] <string>

`(nnchoke-close-group GROUP &optional SERVER)`
  Close group and free any resources connected to it. This will be a no-op on most backends. There should be no data returned.
`(nnchoke-request-list &optional SERVER)`
  Return a list of all groups available on server. And that means all. Here's an example from a server that only carries two groups:

      ifi.test 0000002200 0000002000 y
      ifi.discussion 3324 3300 n

  On each line we have a group name, then the highest article number in that group, the lowest article number, and finally a flag.

      active-file = *active-line
      active-line = name " " <number> " " <number> " " flags eol
      name        = <string>
      flags       = "n" / "y" / "m" / "x" / "j" / "=" name

  The flag says whether the group is read-only (``n'`), is moderated (``m'`), is dead (``x'`), is aliased to some other group (``=other-group'` or none of the above (``y'`).
`(nnchoke-request-post &optional SERVER)`
  This function should post the current buffer. It might return whether the posting was successful or not, but that's not required. If, for instance, the posting is done asynchronously, it has generally not been completed by the time this function concludes. In that case, this function should set up some kind of sentinel to beep the user loud and clear if the posting could not be completed. There should be no result data from this function.

#### Optional Backend Functions

`(nnchoke-retrieve-groups GROUPS &optional SERVER)`
  groups is a list of groups, and this function should request data on all those groups. How it does it is of no concern to Gnus, but it should attempt to do this in a speedy fashion. The return value of this function can be either `active` or `group`, which says what the format of the result data is. The former is in the same format as the data from `nnchoke-request-list`, while the latter is a buffer full of lines in the same format as `nnchoke-request-group` gives.

      group-buffer = *active-line / *group-status

`(nnchoke-request-update-info GROUP INFO &optional SERVER)`
  A Gnus group info (see section Group Info) is handed to the backend for alterations. This comes in handy if the backend really carries all the information (as is the case with virtual an imap groups). This function may alter the info in any manner it sees fit, and should return the (altered) group info. This function may alter the group info destructively, so no copying is needed before boogeying. There should be no result data from this function.
`(nnchoke-request-type GROUP &optional ARTICLE)`
  When the user issues commands for "sending news" (`F` in the summary buffer, for instance), Gnus has to know whether the article the user is following up is news or mail. This function should return `news` if article in group is news, `mail` if it is mail and `unknown` if the type can't be decided. (The article parameter is necessary in `nnvirtual` groups which might very well combine mail groups and news groups.) There should be no result data from this function.
`(nnchoke-request-update-mark GROUP ARTICLE MARK)`
  If the user tries to set a mark that the backend doesn't like, this function may change the mark. Gnus will use whatever this function returns as the mark for article instead of the original mark. If the backend doesn't care, it must return the original mark, and not `nil` or any other type of garbage. The only use for this that I can see is what `nnvirtual` does with it--if a component group is auto-expirable, marking an article as read in the virtual group should result in the article being marked as expirable. There should be no result data from this function.
`(nnchoke-request-scan &optional GROUP SERVER)`
  This function may be called at any time (by Gnus or anything else) to request that the backend check for incoming articles, in one way or another. A mail backend will typically read the spool file or query the POP server when this function is invoked. The group doesn't have to be heeded--if the backend decides that it is too much work just scanning for a single group, it may do a total scan of all groups. It would be nice, however, to keep things local if that's practical. There should be no result data from this function.
`(nnchoke-request-asynchronous GROUP &optional SERVER ARTICLES)`
  This is a request to fetch articles asynchronously later. articles is an alist of (article-number line-number). One would generally expect that if one later fetches article number 4, for instance, some sort of asynchronous fetching of the articles after 4 (which might be 5, 6, 7 or 11, 3, 909 depending on the order in that alist) would be fetched asynchronously, but that is left up to the backend. Gnus doesn't care. There should be no result data from this function.
`(nnchoke-request-group-description GROUP &optional SERVER)`
  The result data from this function should be a description of group.

      description-line = name <TAB> description eol
      name             = <string>
      description      = <text>

`(nnchoke-request-list-newsgroups &optional SERVER)`
  The result data from this function should be the description of all groups available on the server.

      description-buffer = *description-line

`(nnchoke-request-newgroups DATE &optional SERVER)`
  The result data from this function should be all groups that were created after ``date'`, which is in normal human-readable date format. The data should be in the active buffer format.
`(nnchoke-request-create-group GROUP &optional SERVER)`
  This function should create an empty group with name group. There should be no return data.
`(nnchoke-request-expire-articles ARTICLES &optional GROUP SERVER FORCE)`
  This function should run the expiry process on all articles in the articles range (which is currently a simple list of article numbers.) It is left up to the backend to decide how old articles should be before they are removed by this function. If force is non-`nil`, all articles should be deleted, no matter how new they are. This function should return a list of articles that it did not/was not able to delete. There should be no result data returned.
`(nnchoke-request-move-article ARTICLE GROUP SERVER ACCEPT-FORM`
  &optional LAST) This function should move article (which is a number) from group by calling accept-form. This function should ready the article in question for moving by removing any header lines it has added to the article, and generally should "tidy up" the article. Then it should `eval` accept-form in the buffer where the "tidy" article is. This will do the actual copying. If this `eval` returns a non-`nil` value, the article should be removed. If last is `nil`, that means that there is a high likelihood that there will be more requests issued shortly, so that allows some optimizations. The function should return a cons where the car is the group name and the cdr is the article number that the article was entered as. There should be no data returned.
`(nnchoke-request-accept-article GROUP &optional SERVER LAST)`
  This function takes the current buffer and inserts it into group. If last in `nil`, that means that there will be more calls to this function in short order. The function should return a cons where the car is the group name and the cdr is the article number that the article was entered as. There should be no data returned.
`(nnchoke-request-replace-article ARTICLE GROUP BUFFER)`
  This function should remove article (which is a number) from group and insert buffer there instead. There should be no data returned.
`(nnchoke-request-delete-group GROUP FORCE &optional SERVER)`
  This function should delete group. If force, it should really delete all the articles in the group, and then delete the group itself. (If there is such a thing as "the group itself".) There should be no data returned.
`(nnchoke-request-rename-group GROUP NEW-NAME &optional SERVER)`
  This function should rename group into new-name. All articles that are in group should move to new-name. There should be no data returned.

#### Writing New Backends

The various backends share many similarities. `nnml` is just like `nnspool`, but it allows you to edit the articles on the server. `nnmh` is just like `nnml`, but it doesn't use an active file, and it doesn't maintain overview databases. `nndir` is just like `nnml`, but it has no concept of "groups", and it doesn't allow editing articles.

It would make sense if it were possible to "inherit" functions from backends when writing new backends. And, indeed, you can do that if you want to. (You don't have to if you don't want to, of course.)

All the backends declare their public variables and functions by using a package called `nnoo`.

To inherit functions from other backends (and allow other backends to inherit functions from the current backend), you should use the following macros: following.

`nnoo-declare`
  This macro declares the first parameter to be a child of the subsequent parameters. For instance:

      (nnoo-declare nndir
        nnml nnmh)

  `nndir` has here declared that it intends to inherit functions from both `nnml` and `nnmh`.
`defvoo`
  This macro is equivalent to `defvar`, but registers the variable as a public server variable. Most state-oriented variables should be declared with `defvoo` instead of `defvar`. In addition to the normal `defvar` parameters, it takes a list of variables in the parent backends to map the variable to when executing a function in those backends.

      (defvoo nndir-directory nil
        "Where nndir will look for groups."
        nnml-current-directory nnmh-current-directory)

  This means that `nnml-current-directory` will be set to `nndir-directory` when an `nnml` function is called on behalf of `nndir`. (The same with `nnmh`.)
`nnoo-define-basics`
  This macro defines some common functions that almost all backends should have.

      (nnoo-define-basics nndir)

`deffoo`
  This macro is just like `defun` and takes the same parameters. In addition to doing the normal `defun` things, it registers the function as being public so that other backends can inherit it.
`nnoo-map-functions`
  This macro allows mapping of functions from the current backend to functions from the parent backends.

      (nnoo-map-functions nndir
        (nnml-retrieve-headers 0 nndir-current-group 0 0)
        (nnmh-request-article 0 nndir-current-group 0 0))

  This means that when `nndir-retrieve-headers` is called, the first, third, and fourth parameters will be passed on to `nnml-retrieve-headers`, while the second parameter is set to the value of `nndir-current-group`.
`nnoo-import`
  This macro allows importing functions from backends. It should be the last thing in the source file, since it will only define functions that haven't already been defined.

      (nnoo-import nndir
        (nnmh
         nnmh-request-list
         nnmh-request-newgroups)
        (nnml))

  This means that calls to `nndir-request-list` should just be passed on to `nnmh-request-list`, while all public functions from `nnml` that haven't been defined in `nndir` yet should be defined now.

Below is a slightly shortened version of the `nndir` backend.

    ;;; nndir.el -- single directory newsgroup access for Gnus
    ;; Copyright (C) 1995,96 Free Software Foundation, Inc.

    ;;; Code:

    (require 'nnheader)
    (require 'nnmh)
    (require 'nnml)
    (require 'nnoo)
    (eval-when-compile (require 'cl))

    (nnoo-declare nndir
      nnml nnmh)

    (defvoo nndir-directory nil
      "Where nndir will look for groups."
      nnml-current-directory nnmh-current-directory)

    (defvoo nndir-nov-is-evil nil
      "*Non-nil means that nndir will never retrieve NOV headers."
      nnml-nov-is-evil)

    (defvoo nndir-current-group "" nil nnml-current-group nnmh-current-group)
    (defvoo nndir-top-directory nil nil nnml-directory nnmh-directory)
    (defvoo nndir-get-new-mail nil nil nnml-get-new-mail nnmh-get-new-mail)

    (defvoo nndir-status-string "" nil nnmh-status-string)
    (defconst nndir-version "nndir 1.0")

    ;;; Interface functions.

    (nnoo-define-basics nndir)

    (deffoo nndir-open-server (server &optional defs)
      (setq nndir-directory
    	(or (cadr (assq 'nndir-directory defs))
    	    server))
      (unless (assq 'nndir-directory defs)
        (push `(nndir-directory ,server) defs))
      (push `(nndir-current-group
    	  ,(file-name-nondirectory (directory-file-name nndir-directory)))
    	defs)
      (push `(nndir-top-directory
    	  ,(file-name-directory (directory-file-name nndir-directory)))
    	defs)
      (nnoo-change-server 'nndir server defs))

    (nnoo-map-functions nndir
      (nnml-retrieve-headers 0 nndir-current-group 0 0)
      (nnmh-request-article 0 nndir-current-group 0 0)
      (nnmh-request-group nndir-current-group 0 0)
      (nnmh-close-group nndir-current-group 0))

    (nnoo-import nndir
      (nnmh
       nnmh-status-message
       nnmh-request-list
       nnmh-request-newgroups))

    (provide 'nndir)

### Score File Syntax

Score files are meant to be easily parsable, but yet extremely mallable. It was decided that something that had the same read syntax as an Emacs Lisp list would fit that spec.

Here's a typical score file:

    (("summary"
      ("win95" -10000 nil s)
      ("Gnus"))
     ("from"
      ("Lars" -1000))
     (mark -100))

BNF definition of a score file:

    score-file       = "" / "(" *element ")"
    element          = rule / atom
    rule             = string-rule / number-rule / date-rule
    string-rule      = "(" quote string-header quote space *string-match ")"
    number-rule      = "(" quote number-header quote space *number-match ")"
    date-rule        = "(" quote date-header quote space *date-match ")"
    quote            = <ascii 34>
    string-header    = "subject" / "from" / "references" / "message-id" /
                       "xref" / "body" / "head" / "all" / "followup"
    number-header    = "lines" / "chars"
    date-header      = "date"
    string-match     = "(" quote <string> quote [ "" / [ space score [ "" /
                       space date [ "" / [ space string-match-t ] ] ] ] ] ")"
    score            = "nil" / <integer>
    date             = "nil" / <natural number>
    string-match-t   = "nil" / "s" / "substring" / "S" / "Substring" /
                       "r" / "regex" / "R" / "Regex" /
                       "e" / "exact" / "E" / "Exact" /
                       "f" / "fuzzy" / "F" / "Fuzzy"
    number-match     = "(" <integer> [ "" / [ space score [ "" /
                       space date [ "" / [ space number-match-t ] ] ] ] ] ")"
    number-match-t   = "nil" / "=" / "<" / ">" / ">=" / "<="
    date-match       = "(" quote <string> quote [ "" / [ space score [ "" /
                       space date [ "" / [ space date-match-t ] ] ] ] ")"
    date-match-t     = "nil" / "at" / "before" / "after"
    atom             = "(" [ required-atom / optional-atom ] ")"
    required-atom    = mark / expunge / mark-and-expunge / files /
                       exclude-files / read-only / touched
    optional-atom    = adapt / local / eval
    mark             = "mark" space nil-or-number
    nil-or-number    = "nil" / <integer>
    expunge          = "expunge" space nil-or-number
    mark-and-expunge = "mark-and-expunge" space nil-or-number
    files            = "files" *[ space <string> ]
    exclude-files    = "exclude-files" *[ space <string> ]
    read-only        = "read-only" [ space "nil" / space "t" ]
    adapt            = "adapt" [ space "nil" / space "t" / space adapt-rule ]
    adapt-rule       = "(" *[ <string> *[ "(" <string> <integer> ")" ] ")"
    local            = "local" *[ space "(" <string> space <form> ")" ]
    eval             = "eval" space <form>
    space            = *[ " " / <TAB> / <NEWLINE> ]

Any unrecognized elements in a score file should be ignored, but not discarded.

As you can see, white space is needed, but the type and amount of white space is irrelevant. This means that formatting of the score file is left up to the programmer--if it's simpler to just spew it all out on one looong line, then that's ok.

The meaning of the various atoms are explained elsewhere in this manual.

### Headers

Gnus uses internally a format for storing article headers that corresponds to the NOV format in a mysterious fashion. One could almost suspect that the author looked at the NOV specification and just shamelessly stole the entire thing, and one would be right.

Header is a severely overloaded term. "Header" is used in RFC1036 to talk about lines in the head of an article (eg., `From`). It is used by many people as a synonym for "head"---"the header and the body". (That should be avoided, in my opinion.) And Gnus uses a format internally that it calls "header", which is what I'm talking about here. This is a 9-element vector, basically, with each header (ouch) having one slot.

These slots are, in order: `number`, `subject`, `from`, `date`, `id`, `references`, `chars`, `lines`, `xref`. There are macros for accessing and setting these slots -- they all have predictable names beginning with `mail-header-` and `mail-header-set-`, respectively.

The `xref` slot is really a `misc` slot. Any extra info will be put in there.

### Ranges

GNUS introduced a concept that I found so useful that I've started using it a lot and have elaborated on it greatly.

The question is simple: If you have a large amount of objects that are identified by numbers (say, articles, to take a wild example) that you want to callify as being "included", a normal sequence isn't very useful. (A 200,000 length sequence is a bit long-winded.)

The solution is as simple as the question: You just collapse the sequence.

    (1 2 3 4 5 6 10 11 12)

is transformed into

    ((1 . 6) (10 . 12))

To avoid having those nasty ``(13 . 13)'` elements to denote a lonesome object, a ``13'` is a valid element:

    ((1 . 6) 7 (10 . 12))

This means that comparing two ranges to find out whether they are equal is slightly tricky:

    ((1 . 5) 7 8 (10 . 12))

and

    ((1 . 5) (7 . 8) (10 . 12))

are equal. In fact, any non-descending list is a range:

    (1 2 3 4 5)

is a perfectly valid range, although a pretty long-winded one. This is also legal:

    (1 . 5)

and is equal to the previous range.

Here's a BNF definition of ranges. Of course, one must remember the semantic requirement that the numbers are non-descending. (Any number of repetition of the same number is allowed, but apt to disappear in range handling.)

    range           = simple-range / normal-range
    simple-range    = "(" number " . " number ")"
    normal-range    = "(" start-contents ")"
    contents        = "" / simple-range *[ " " contents ] /
                      number *[ " " contents ]

Gnus currently uses ranges to keep track of read articles and article marks. I plan on implementing a number of range operators in C if The Powers That Be are willing to let me. (I haven't asked yet, because I need to do some more thinking on what operators I need to make life totally range-based without ever having to convert back to normal sequences.)

### Group Info

Gnus stores all permanent info on groups in a group info list. This list is from three to six elements (or more) long and exhaustively describes the group.

Here are two example group infos; one is a very simple group while the second is a more complex one:

    ("no.group" 5 (1 . 54324))

    ("nnml:my.mail" 3 ((1 . 5) 9 (20 . 55))
                    ((tick (15 . 19)) (replied 3 6 (19 . 3)))
                    (nnml "")
                    (auto-expire (to-address "ding@ifi.uio.no")))

The first element is the group name as Gnus knows the group; the second is the group level; the third is the read articles in range format; the fourth is a list of article marks lists; the fifth is the select method; and the sixth contains the group parameters.

Here's a BNF definition of the group info format:

    info          = "(" group space level space read
                    [ "" / [ space marks-list [ "" / [ space method [ "" /
                    space parameters ] ] ] ] ] ")"
    group         = quote <string> quote
    level         = <integer in the range of 1 to inf>
    read          = range
    marks-lists   = nil / "(" *marks ")"
    marks         = "(" <string> range ")"
    method        = "(" <string> *elisp-forms ")"
    parameters    = "(" *elisp-forms ")"

Actually that ``marks'` rule is a fib. A ``marks'` is a ``<string>'` consed on to a ``range'`, but that's a bitch to say in pseudo-BNF.

### Emacs/XEmacs Code

While Gnus runs under Emacs, XEmacs and Mule, I decided that one of the platforms must be the primary one. I chose Emacs. Not because I don't like XEmacs or Mule, but because it comes first alphabetically.

This means that Gnus will byte-compile under Emacs with nary a warning, while XEmacs will pump out gigabytes of warnings while byte-compiling. As I use byte-compilation warnings to help me root out trivial errors in Gnus, that's very useful.

I've also consistently used Emacs function interfaces, but have used Gnusey aliases for the functions. To take an example: Emacs defines a `run-at-time` function while XEmacs defines a `start-itimer` function. I then define a function called `gnus-run-at-time` that takes the same parameters as the Emacs `run-at-time`. When running Gnus under Emacs, the former function is just an alias for the latter. However, when running under XEmacs, the former is an alias for the following function:

    (defun gnus-xmas-run-at-time (time repeat function &rest args)
      (start-itimer
       "gnus-run-at-time"
       `(lambda ()
          (,function ,@args))
       time repeat))

This sort of thing has been done for bunches of functions. Gnus does not redefine any native Emacs functions while running under XEmacs -- it does this `defalias` thing with Gnus equivalents instead. Cleaner all over.

Of course, I could have chosen XEmacs as my native platform and done mapping functions the other way around. But I didn't. The performance hit these indirections impose on Gnus under XEmacs should be slight.

### Various File Formats

- Active File Format: Information on articles and groups available.
- Newsgroups File Format: Group descriptions.

#### Active File Format

The active file lists all groups that are available on the server in question. It also lists the highest and lowest current article numbers in each group.

Here's an excerpt from a typical active file:

    soc.motss 296030 293865 y
    alt.binaries.pictures.fractals 3922 3913 n
    comp.sources.unix 1605 1593 m
    comp.binaries.ibm.pc 5097 5089 y
    no.general 1000 900 y

Here's a pseudo-BNF definition of this file:

    active      = *group-line
    group-line  = group space high-number space low-number space flag <NEWLINE>
    group       = <non-white-space string>
    space       = " "
    high-number = <non-negative integer>
    low-number  = <positive integer>
    flag        = "y" / "n" / "m" / "j" / "x" / "=" group

#### Newsgroups File Format

The newsgroups file lists groups along with their descriptions. Not all groups on the server have to be listed, and not all groups in the file have to exist on the server. The file is meant purely as information to the user.

The format is quite simple; a group name, a tab, and the description. Here's the definition:

    newsgroups    = *line
    line          = group tab description <NEWLINE>
    group         = <non-white-space string>
    tab           = <TAB>
    description   = <string>

## Emacs for Heathens

Believe it or not, but some people who use Gnus haven't really used Emacs much before they embarked on their journey on the Gnus Love Boat. If you are one of those unfortunates whom "`M-C-a`", "kill the region", and "set `gnus-flargblossen` to an alist where the key is a regexp that is used for matching on the group name" are magical phrases with little or no meaning, then this appendix is for you. If you are already familiar with Emacs, just ignore this and go fondle your cat instead.

- Keystrokes: Entering text and executing commands.
- Emacs Lisp: The built-in Emacs programming language.

### Keystrokes

- Q: What is an experienced Emacs user?
- A: A person who wishes that the terminal had pedals.

Yes, when you use Emacs, you are apt to use the control key, the shift key and the meta key a lot. This is very annoying to some people (notably `vi`le users), and the rest of us just love the hell out of it. Just give up and submit. Emacs really does stand for "Escape-Meta-Alt-Control-Shift", and not "Editing Macros", as you may have heard from other disreputable sources (like the Emacs author).

The shift key is normally located near your pinky fingers, and are normally used to get capital letters and stuff. You probably use it all the time. The control key is normally marked "CTRL" or something like that. The meta key is, funnily enough, never marked as such on any keyboards. The one I'm currently at has a key that's marked "Alt", which is the meta key on this keyboard. It's usually located somewhere to the left hand side of the keyboard, usually on the bottom row.

Now, us Emacs people doesn't say "press the meta-control-m key", because that's just too inconvenient. We say "press the `M-C-m` key". `M-` is the prefix that means "meta" and "C-" is the prefix that means "control". So "press `C-k`" means "press down the control key, and hold it down while you press `k`". "Press `M-C-k`" means "press down and hold down the meta key and the control key and then press `k`". Simple, ay?

This is somewhat complicated by the fact that not all keyboards have a meta key. In that case you can use the "escape" key. Then `M-k` means "press escape, release escape, press `k`". That's much more work than if you have a meta key, so if that's the case, I respectfully suggest you get a real keyboard with a meta key. You can't live without it.

### Emacs Lisp

Emacs is the King of Editors because it's really a Lisp interpreter. Each and every key you tap runs some Emacs Lisp code snippet, and since Emacs Lisp is an interpreted language, that means that you can configure any key to run any arbitrary code. You just, like, do it.

Gnus is written in Emacs Lisp, and is run as a bunch of interpreted functions. (These are byte-compiled for speed, but it's still interpreted.) If you decide that you don't like the way Gnus does certain things, it's trivial to have it do something a different way. (Well, at least if you know how to write Lisp code.) However, that's beyond the scope of this manual, so we are simply going to talk about some common constructs that you normally use in your ``.emacs'` file to customize Gnus.

If you want to set the variable `gnus-florgbnize` to four (4), you write the following:

    (setq gnus-florgbnize 4)

This function (really "special form") `setq` is the one that can set a variable to some value. This is really all you need to know. Now you can go and fill your `.emacs` file with lots of these to change how Gnus works.

If you have put that thing in your `.emacs` file, it will be read and `eval`ed (which is lisp-ese for "run") the next time you start Emacs. If you want to change the variable right away, simply say `C-x C-e` after the closing parenthesis. That will `eval` the previous "form", which here is a simple `setq` statement.

Go ahead--just try it, if you're located at your Emacs. After you `C-x C-e`, you will see ``4'` appear in the echo area, which is the return value of the form you `eval`ed.

Some pitfalls:

If the manual says "set `gnus-read-active-file` to `some`", that means:

    (setq gnus-read-active-file 'some)

On the other hand, if the manual says "set `gnus-nntp-server` to ``nntp.ifi.uio.no'`", that means:

    (setq gnus-nntp-server "nntp.ifi.uio.no")

So be careful not to mix up strings (the latter) with symbols (the former). The manual is unambiguous, but it can be confusing.

\input texinfo

## Frequently Asked Questions

This is the Gnus Frequently Asked Questions list. If you have a Web browser, the official hypertext version is at ``http://www.miranova.com/~steve/gnus-faq.html>'`, and has probably been updated since you got this manual.

- Installation FAQ: Installation of Gnus.
- Customization FAQ: Customizing Gnus.
- Reading News FAQ: News Reading Questions.
- Reading Mail FAQ: Mail Reading Questions.

### Installation

- Q1.1 What is the latest version of Gnus? The latest (and greatest) version is 5.0.10. You might also run across something called September Gnus. September Gnus is the alpha version of the next major release of Gnus. It is currently not stable enough to run unless you are prepared to debug lisp.
- Q1.2 Where do I get Gnus? Any of the following locations:
  - ``ftp://ftp.ifi.uio.no/pub/emacs/gnus/gnus.tar.gz'`
  - ``ftp://ftp.pilgrim.umass.edu/pub/misc/ding/'`
  - ``gopher://gopher.pilgrim.umass.edu/11/pub/misc/ding/'`
  - ``ftp://aphrodite.nectar.cs.cmu.edu/pub/ding-gnus/'`
  - ``ftp://ftp.solace.mh.se:/pub/gnu/elisp/'`
- Q1.3 Which version of Emacs do I need? At least GNU Emacs 19.28, or XEmacs 19.12 is recommended. GNU Emacs 19.25 has been reported to work under certain circumstances, but it doesn't officially work on it. 19.27 has also been reported to work. Gnus has been reported to work under OS/2 as well as Unix.
- Q1.4 Where is timezone.el? Upgrade to XEmacs 19.13. In earlier versions of XEmacs this file was placed with Gnus 4.1.3, but that has been corrected.
- Q1.5 When I run Gnus on XEmacs 19.13 I get weird error messages. You're running an old version of Gnus. Upgrade to at least version 5.0.4.
- Q1.6 How do I unsubscribe from the Mailing List? Send an e-mail message to ``ding-request@ifi.uio.no'` with the magic word unsubscribe somewhere in it, and you will be removed. If you are reading the digest version of the list, send an e-mail message to
  ``ding-rn-digests-d-request@moe.shore.net'` with unsubscribe as the subject and you will be removed.
- Q1.7 How do I run Gnus on both Emacs and XEmacs? The basic answer is to byte-compile under XEmacs, and then you can run under either Emacsen. There is, however, a potential version problem with easymenu.el with Gnu Emacs prior to 19.29. Per Abrahamsen <abraham@dina.kvl.dk> writes :
  The internal easymenu.el interface changed between 19.28 and 19.29 in order to make it possible to create byte compiled files that can be shared between Gnu Emacs and XEmacs. The change is upward compatible, but not downward compatible. This gives the following compatibility table:

      Compiled with:  | Can be used with:
      ----------------+--------------------------------------
      19.28           | 19.28         19.29
      19.29           |               19.29           XEmacs
      XEmacs          |               19.29           XEmacs

  If you have Gnu Emacs 19.28 or earlier, or XEmacs 19.12 or earlier, get a recent version of auc-menu.el from ``ftp://ftp.iesd.auc.dk/pub/emacs-lisp/auc-menu.el'`, and install it under the name easymenu.el somewhere early in your load path.
- Q1.8 What resources are available? There is the newsgroup Gnu.emacs.gnus. Discussion of Gnus 5.x is now taking place there. There is also a mailing list, send mail to ``ding-request@ifi.uio.no'` with the magic word subscribe somewhere in it. NOTE: the traffic on this list is heavy so you may not want to be on it (unless you use Gnus as your mailer reader, that is). The mailing list is mainly for developers and testers. Gnus has a home World Wide Web page at
  ``http://www.ifi.uio.no/~larsi/ding.html'`. Gnus has a write up in the X Windows Applications FAQ at
  ``http://www.ee.ryerson.ca:8080/~elf/xapps/Q-III.html'`. The Gnus manual is also available on the World Wide Web. The canonical source is in Norway at
  ``http://www.ifi.uio.no/~larsi/ding-manual/gnus_toc.html'`. There are three mirrors in the United States:
  1. ``http://www.miranova.com/gnus-man/'`
  2. ``http://www.pilgrim.umass.edu/pub/misc/ding/manual/gnus_toc.html'`
  3. ``http://www.rtd.com/~woo/gnus/'`
  PostScript copies of the Gnus Reference card are available from
  ``ftp://ftp.cs.ualberta.ca/pub/oolog/gnus/'`. They are mirrored at
  ``ftp://ftp.pilgrim.umass.edu/pub/misc/ding/refcard/'` in the United States. And
  ``ftp://marvin.fkphy.uni-duesseldorf.de/pub/gnus/'` in Germany. An online version of the Gnus FAQ is available at
  ``http://www.miranova.com/~steve/gnus-faq.html'`. Off-line formats are also available:
  ASCII: ``ftp://ftp.miranova.com/pub/gnus/gnus-faq'`
  PostScript: ``ftp://ftp.miranova.com/pub/gnus/gnus-faq.ps'`.
- Q1.9 Gnus hangs on connecting to NNTP server I am running XEmacs on SunOS and Gnus prints a message about Connecting to NNTP server and then just hangs. Ben Wing <wing@netcom.com> writes :
  I wonder if you're hitting the infamous libresolv problem. The basic problem is that under SunOS you can compile either with DNS or NIS name lookup libraries but not both. Try substituting the IP address and see if that works; if so, you need to download the sources and recompile.
- Q1.10 Mailcrypt 3.4 doesn't work This problem is verified to still exist in Gnus 5.0.9 and MailCrypt 3.4. The answer comes from Peter Arius <arius@immd2.informatik.uni-erlangen.de>. I found out that mailcrypt uses `gnus-eval-in-buffer-window`, which is a macro. It seems as if you have compiled mailcrypt with plain old GNUS in load path, and the XEmacs byte compiler has inserted that macro definition into ``mc-toplev.elc'`. The solution is to recompile ``mc-toplev.el'` with Gnus 5 in load-path, and it works fine. Steve Baur <steve@miranova.com> adds :
  The problem also manifests itself if neither GNUS 4 nor Gnus 5 is in the load-path.
- Q1.11 What other packages work with Gnus?
  - Mailcrypt. Mailcrypt is an Emacs interface to PGP. It works, it installs without hassle, and integrates very easily. Mailcrypt can be obtained from
    ``ftp://cag.lcs.mit.edu/pub/patl/mailcrypt-3.4.tar.gz'`.
  - Tiny Mime. Tiny Mime is an Emacs MUA interface to MIME. Installation is a two-step process unlike most other packages, so you should be prepared to move the byte-compiled code somewhere. There are currently two versions of this package available. It can be obtained from
    ``ftp://ftp.jaist.ac.jp/pub/GNU/elisp/'`. Be sure to apply the supplied patch. It works with Gnus through version 5.0.9. In order for all dependencies to work correctly the load sequence is as follows:

          (load "tm-setup")
          (load "gnus")
          (load "mime-compose")

    NOTE: Loading the package disables citation highlighting by default. To get the old behavior back, use the `M-t` command.

### Customization

- Q2.1 Custom Edit does not work under XEmacs The custom package has not been ported to XEmacs.
- Q2.2 How do I quote messages? I see lots of messages with quoted material in them. I am wondering how to have Gnus do it for me. This is Gnus, so there are a number of ways of doing this. You can use the built-in commands to do this. There are the `F` and `R` keys from the summary buffer which automatically include the article being responded to. These commands are also selectable as Followup and Yank and Reply and Yank in the Post menu. `C-c C-y` grabs the previous message and prefixes each line with `ail-indentation-spaces` spaces or `mail-yank-prefix` if that is non-nil, unless you have set your own `mail-citation-hook`, which will be called to to do the job. You might also consider the Supercite package, which allows for pretty arbitrarily complex quoting styles. Some people love it, some people hate it.
- Q2.3 How can I keep my nnvirtual:* groups sorted? How can I most efficiently arrange matters so as to keep my nnvirtual:* (etc) groups at the top of my group selection buffer, whilst keeping everything sorted in alphabetical order. If you don't subscribe often to new groups then the easiest way is to first sort the groups and then manually kill and yank the virtuals wherever you want them.
- Q2.4 Any good suggestions on stuff for an all.SCORE file? Here is a collection of suggestions from the Gnus mailing list.
  1. From "Dave Disser" <disser@sdd.hp.com>
     I like blasting anything without lowercase letters. Weeds out most of the make $$ fast, as well as the lame titles like "IBM" and "HP-UX" with no further description.

          (("Subject"
           ("^\\(Re: \\)?[^a-z]*$" -200 nil R)))

  2. From "Peter Arius" <arius@immd2.informatik.uni-erlangen.de>
     The most vital entries in my (still young) all.SCORE:

         (("xref"
           ("alt.fan.oj-simpson" -1000 nil s))
          ("subject"
           ("\\<\\(make\\|fast\\|big\\)\\s-*\\(money\\|cash\\|bucks?\\)\\>" -1000 nil r)
           ("$$$$" -1000 nil s)))

  3. From "Per Abrahamsen" <abraham@dina.kvl.dk>

         (("subject"
           ;; CAPS OF THE WORLD, UNITE
           ("^..[^a-z]+$" -1 nil R)
           ;; $$$ Make Money $$$ (Try work)
           ("$" -1 nil s)
           ;; I'm important! And I have exclamation marks to prove it!
           ("!" -1 nil s)))

  4. From "heddy boubaker" <boubaker@cenatls.cena.dgac.fr>
     I would like to contribute with mine.

         (
          (read-only t)
          ("subject"
           ;; ALL CAPS SUBJECTS
           ("^\\([Rr][Ee]: +\\)?[^a-z]+$" -1 nil R)
           ;; $$$ Make Money $$$
           ("$$" -10 nil s)
           ;; Empty subjects are worthless!
           ("^ *\\([(<]none[>)]\\|(no subject\\( given\\)?)\\)? *$" -10 nil r)
           ;; Sometimes interesting announces occur!
           ("ANN?OU?NC\\(E\\|ING\\)" +10 nil r)
           ;; Some people think they're on mailing lists
           ("\\(un\\)?sub?scribe" -100 nil r)
           ;; Stop Micro$oft NOW!!
           ("\\(m\\(icro\\)?[s$]\\(oft\\|lot\\)?-?\\)?wind?\\(ows\\|aube\\|oze\\)?[- ]*\\('?95\\|NT\\|3[.]1\\|32\\)" -1001 nil r)
           ;; I've nothing to buy
           ("\\(for\\|4\\)[- ]*sale" -100 nil r)
           ;; SELF-DISCIPLINED people
           ("\\[[^a-z0-9 \t\n][^a-z0-9 \t\n]\\]" +100 nil r)
           )
          ("from"
           ;; To keep track of posters from my site
           (".dgac.fr" +1000 nil s))
          ("followup"
           ;; Keep track of answers to my posts
           ("boubaker" +1000 nil s))
          ("lines"
           ;; Some people have really nothing to say!!
           (1 -10 nil <=))
          (mark -100)
          (expunge -1000)
          )

  5. From "Christopher Jones" <cjones@au.oracle.com>
     The sample ``all.SCORE'` files from Per and boubaker could be augmented with:

         	(("subject"
         	  ;; No junk mail please!
         	  ("please ignore" -500 nil s)
         	  ("test" -500 nil e))
         	)

  6. From "Brian Edmonds" <edmonds@cs.ubc.ca>
     Augment any of the above with a fast method of scoring down excessively cross posted articles.

          ("xref"
           ;; the more cross posting, the exponentially worse the article
           ("^xref: \\S-+ \\S-+ \\S-+ \\S-+" -1 nil r)
           ("^xref: \\S-+ \\S-+ \\S-+ \\S-+ \\S-+" -2 nil r)
           ("^xref: \\S-+ \\S-+ \\S-+ \\S-+ \\S-+ \\S-+" -4 nil r)
           ("^xref: \\S-+ \\S-+ \\S-+ \\S-+ \\S-+ \\S-+ \\S-+" -8 nil r)
           ("^xref: \\S-+ \\S-+ \\S-+ \\S-+ \\S-+ \\S-+ \\S-+ \\S-+" -16 nil r)
           ("^xref: \\S-+ \\S-+ \\S-+ \\S-+ \\S-+ \\S-+ \\S-+ \\S-+ \\S-+" -32 nil r)
           ("^xref: \\S-+ \\S-+ \\S-+ \\S-+ \\S-+ \\S-+ \\S-+ \\S-+ \\S-+ \\S-+" -64 nil r)
           ("^xref: \\S-+ \\S-+ \\S-+ \\S-+ \\S-+ \\S-+ \\S-+ \\S-+ \\S-+ \\S-+ \\S-+" -128 nil r)
           ("^xref: \\S-+ \\S-+ \\S-+ \\S-+ \\S-+ \\S-+ \\S-+ \\S-+ \\S-+ \\S-+ \\S-+ \\S-+" -256 nil r)
           ("^xref: \\S-+ \\S-+ \\S-+ \\S-+ \\S-+ \\S-+ \\S-+ \\S-+ \\S-+ \\S-+ \\S-+ \\S-+ \\S-+" -512 nil r))

- Q2.5 What do I use to yank-through when replying? You should probably reply and followup with `R` and `F`, instead of `r` and `f`, which solves your problem. But you could try something like:

      (defconst mail-yank-ignored-headers
        "^.*:"
        "Delete these headers from old message when it's inserted in a reply.")

- Q2.6 I don't like the default WWW browser Now when choosing an URL Gnus starts up a W3 buffer, I would like it to always use Netscape (I don't browse in text-mode ;-).
  1. Activate `Customize...' from the `Help' menu.
  2. Scroll down to the `WWW Browser' field.
  3. Click `mouse-2' on `WWW Browser'.
  4. Select `Netscape' from the pop up menu.
  5. Press `C-c C-c'
  If you are using XEmacs then to specify Netscape do

        (setq gnus-button-url 'gnus-netscape-open-url)

- Q2.7 What, if any, relation is between "ask-server" and "(setq gnus-read-active-file 'some)"? In order for Gnus to show you the complete list of newsgroups, it will either have to either store the list locally, or ask the server to transmit the list. You enable the first with

              (setq gnus-save-killed-list t)

  and the second with

              (setq gnus-read-active-file t)

  If both are disabled, Gnus will not know what newsgroups exists. There is no option to get the list by casting a spell.
- Q2.8 Moving between groups is slow. Per Abrahamsen <abraham@dina.kvl.dk> writes:
  Do you call `define-key` or something like that in one of the summary mode hooks? This would force Emacs to recalculate the keyboard shortcuts. Removing the call should speed up `M-x gnus-summary-mode RET` by a couple of orders of magnitude. You can use

      (define-key gnus-summary-mode-map KEY COMMAND)

  in your ``.gnus'` instead.

### Reading News

- Q3.1 How do I convert my kill files to score files? A kill-to-score translator was written by Ethan Bradford <ethanb@ptolemy.astro.washington.edu>. It is available from
  ``http://baugi.ifi.uio.no/~larsi/ding-various/gnus-kill-to-score.el'`.
- Q3.2 My news server has a lot of groups, and killing groups is painfully slow. Don't do that then. The best way to get rid of groups that should be dead is to edit your newsrc directly. This problem will be addressed in the near future.
- Q3.3 How do I use an NNTP server with authentication? Put the following into your .gnus:

       (add-hook 'nntp-server-opened-hook 'nntp-send-authinfo)

- Q3.4 Not reading the first article. How do I avoid reading the first article when a group is selected?
  1. Use `RET` to select the group instead of `SPC`.
  2. `(setq gnus-auto-select first nil)`
  3. Luis Fernandes <elf@mailhost.ee.ryerson.ca>writes:
     This is what I use...customize as necessary...

         ;;; Don't auto-select first article if reading sources, or archives or
         ;;; jobs postings, etc. and just display the summary buffer
         (add-hook 'gnus-select-group-hook
         	  (function
         	   (lambda ()
         	     (cond ((string-match "sources" gnus-newsgroup-name)
         		    (setq gnus-auto-select-first nil))
         			   ((string-match "jobs" gnus-newsgroup-name)
         				(setq gnus-auto-select-first nil))
         		   ((string-match "comp\\.archives" gnus-newsgroup-name)
         		    (setq gnus-auto-select-first nil))
         		   ((string-match "reviews" gnus-newsgroup-name)
         		    (setq gnus-auto-select-first nil))
         		   ((string-match "announce" gnus-newsgroup-name)
         		    (setq gnus-auto-select-first nil))
         		   ((string-match "binaries" gnus-newsgroup-name)
         		    (setq gnus-auto-select-first nil))
         		   (t
         		    (setq gnus-auto-select-first t))))))

  4. Per Abrahamsen <abraham@dina.kvl.dk> writes:
     Another possibility is to create an ``all.binaries.all.SCORE'` file like this:

         ((local
           (gnus-auto-select-first nil)))

     and insert

         	(setq gnus-auto-select-first t)

     in your ``.gnus'`.
- Q3.5 Why aren't BBDB known posters marked in the summary buffer? Brian Edmonds <edmonds@cs.ubc.ca> writes:
  Due to changes in Gnus 5.0, ``bbdb-gnus.el'` no longer marks known posters in the summary buffer. An updated version, ``gnus-bbdb.el'` is available at the locations listed below. This package also supports autofiling of incoming mail to folders specified in the BBDB. Extensive instructions are included as comments in the file. Send mail to ``majordomo@edmonds.home.cs.ubc.ca'` with the following line in the body of the message: get misc gnus-bbdb.el. Or get it from the World Wide Web:
  ``http://www.cs.ubc.ca/spider/edmonds/gnus-bbdb.el'`.

### Reading Mail

- Q4.1 What does the message "Buffer has changed on disk" mean in a mail group? Your filter program should not deliver mail directly to your folders, instead it should put the mail into spool files. Gnus will then move the mail safely from the spool files into the folders. This will eliminate the problem. Look it up in the manual, in the section entitled "Mail & Procmail".
- Q4.2 How do you make articles un-expirable? I am using nnml to read news and have used `gnus-auto-expirable-newsgroups` to automagically expire articles in some groups (Gnus being one of them). Sometimes there are interesting articles in these groups that I want to keep. Is there any way of explicitly marking an article as un-expirable - that is mark it as read but not expirable? Use `u`, `!`, `d` or `M-u` in the summary buffer. You just remove the `E` mark by setting some other mark. It's not necessary to tick the articles.
- Q4.3 How do I delete bogus nnml: groups? My problem is that I have various mail (nnml) groups generated while experimenting with Gnus. How do I remove them now? Setting the level to 9 does not help. Also `gnus-group-check-bogus-groups` does not recognize them. Removing mail groups is tricky at the moment. (It's on the to-do list, though.) You basically have to kill the groups in Gnus, shut down Gnus, edit the active file to exclude these groups, and probably remove the nnml directories that contained these groups as well. Then start Gnus back up again.
- Q4.4 What happened to my new mail groups? I got new mail, but I have never seen the groups they should have been placed in. They are probably there, but as zombies. Press `A z` to list zombie groups, and then subscribe to the groups you want with `u`. This is all documented quite nicely in the user's manual.
- Q4.5 Not scoring mail groups How do you totally turn off scoring in mail groups? Use an nnbabyl:all.SCORE (or nnmh, or nnml, or whatever) file containing:

      ((adapt ignore)
       (local (gnus-use-scoring nil))
       (exclude-files "all.SCORE"))

Go to the first, previous, next, last section, table of contents.