History

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.

• Why?: What's the point of Gnus?
• Compatibility: Just how compatible is Gnus with GNUS?
• Conformity: Gnus tries to conform to all standards.
• 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 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.

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

Conformity

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.

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 see Gnus act noncompliantly to the texts mentioned above, don't hesitate to drop a note to Gnus Towers and let us know.

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

• Of course, GNUS was written by Masanobu UMEDA.
• Many excellent functions, especially dealing with scoring and highlighting (as well as the soon-to-come SOUP support) was written by Per Abrahamsen.
• Innumerable bug fixes were written by Sudish Joseph.
• The refcard was written by Vladimir Alexiev.
• I stole some pieces from the XGnus distribution by Felix Lee and JWZ.
• nnfolder has been much enhanced by Scott Byer.
• The orphan scoring was written by Peter Mutsaers.
• GNU XEmacs support has been added by Fabrice Popineau.
• Various bits and pieces, especially dealing with .newsrc files, was suggested and added by Hallvard B Furuseth.
• Brian Edmonds has written gnus-bbdb, as well as other bits and pieces.
• Ricardo Nassif did the proof-reading.
• Kevin Davidson came up with the name ding, so blame him.
• Stainless Steel Rat, Ulrik Dickow, Jack Vinson, Daniel Quinlan, Ilja Weis, Frank D. Cringle, Geoffrey T. Dairiki 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 Foreign Groups).
• You can combine groups into virtual groups (see section nnvirtual).
• You can read a number of different mail formats (see section Reading Mail). All the mail backends implement a convenient mail expiry scheme (Expiring Old Mail Articles).
• Gnus can use various strategies for gathering threads that have lost their roots (thereby gathering loose sub-threads in 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.
• 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 Score Files). You can even get Gnus 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 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 nnkiboze).
• 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 & Posting).
• Fetching parents (and other articles) now actually works without glitches (see section Finding the Parent).
• Gnus can fetch FAQs to and descriptions of groups (see section Group Information).
• Digests (and other files) can be used as the basis for groups (see section nndoc).
• Articles can be highlighted and customized (see section Customizing Articles).
• All Gnus buffers can be customized in a difficult fashion (see section Windows Configuration).
• You can click on buttons instead of using the keyboard (see section Buttons).

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. I was hoping I could steal code from Mew, the MIME mail reader for Emacs, but I'm not quite sure what the status of that project is. Gnus might support MIME quite soon, and it might not.
• trn-like trees.
• nn-like pick-and-read summary interface.
• NoCeM support.
• Frame configuration.
• Re-sending bounced mail and rejected articles.
• Floating point group levels and group bubbling.
• `/etc/nntpserver' usage.
• Automatic re-scan of incoming mail.
• Buttonize more stuff in the article buffer.
• A better and simpler method for specifying mail composing methods.
• Marks for saved, forwarded, etc articles.
• Speed up caching and adaptive scoring.
• Gather thread by filling in missing Message-IDs.
• Slave Gnusii to enable several Gnusii to run at once.
• PGP support.
• Allow posting through mail-to-news gateways.
• Allow renaming mail groups in a simple fashion.
• Speed up massive group massacres.
• jka-compr isn't fully supported.
• Create better digests.
• Do better word-wrap on cited text.
• Better X-Face support with X-Face databases and stuff.
• Support SELF-DISCIPLINE pins.
• Really do unbinhexing.
• Fetching by Message-ID should work in mail groups.
• Listing of all active groups.
• XEmacs toolbar.
• Do the X-Receipt-To thing.
• Hierarchal group buffers.
• Don't kill summary buffers upon exit from the groups.
• Allow adaption on secondary marks.

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