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


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

The recommended pronunciation of the name this program is "ding guh-noose", with "ding" being half-sung in a loud, high-pitched voice, and "guh-noose" being grumbled and a disaffected fashion. Any irritation and/or damage this name may cause you is not the responsibility of the author, even though you might like to strangle him for the stupid idea.

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, also know as The Site That Destroys Newsrcs And Drives People Mad.

During the first extended alpha period of develpment, 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 with coming up with a new and spiffy name, we decided that the name was too spiffy, so we renamamed it back again to "Gnus". But in mixed case. "Gnus" vs. GNUS. New vs. old.

Incidentally, the next Gnus generation will be called "September Gnus", and won't be released until February. Confused? You will be.


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 hundreds (or thousands) of new articles each day?

Gnus offer 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 can imagine useful. By doing so, I'm inviting every one of you to explore and invent new ways of reading news.

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


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 if 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 most 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-assoc (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 assoc (which speeds up many functions), and changing the assoc 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, gnus-summary-prepare-hook and gnus-summary-article-hook). (Well, at the very least the first two.) 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 (M-x gnus-bug).

Problems specific to GNU XEmacs can be reported to popineau@ese-metz.fr (Fabrice Popineau). I will just forward any such questions to him, anyway, so you might have to wait longer if you mail XEmacs questions to me.


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

RFC 822
There are no known breaches to this standard.
RFC 1036
There are no known breaches to 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 that Gnus would pass.
Son-of-RFC 1036
We do have some breaches to this one.
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.
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.
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 see Gnus act noncompliantly to the texts mentioned above, don't hesitate to drop a note to Gnus Towers and let us know.


The new Gnus version couldn't have been done without the help of all the people on the (ding) mailing list. Every day for months I have gotten tens 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. Microsoft - bah. I'm much worse.

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

New Features

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.

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

You can probably sneak a look at the actual up-to-the-second todo list by snooping <URL:http://www.ifi.uio.no/~larsi/sgnus/todo>.

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