This is Info file ../info/gnus, produced by Makeinfo-1.55 from the input file gnus.texi. This file documents Gnus, the GNU Emacs newsreader. Copyright (C) 1995 Free Software Foundation, Inc. Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies. Permission is granted to copy and distribute modified versions of this manual under the conditions for verbatim copying, provided also that the entire resulting derived work is distributed under the terms of a permission notice identical to this one. Permission is granted to copy and distribute translations of this manual into another language, under the above conditions for modified versions.  File: gnus, Node: Top, Next: History, Prev: (DIR), Up: (DIR) The Gnus Newsreader ******************* You can read news (and mail) from within Emacs by using Gnus. The news can be gotten by any nefarious means you can think of - NNTP, local spool or your mbox file. All at the same time, if you want to push your luck. * Menu: * History:: How Gnus got where it is today. * Terminology:: We use really difficult, like, words here. * Starting Up:: Finding news can be a pain. * The Group Buffer:: Selecting, subscribing and killing groups. * The Summary Buffer:: Reading, saving and posting articles. * The Article Buffer:: Displaying and handling articles. * The Server Buffer:: Making and editing virtual servers. * Various:: General purpose settings. * Customization:: Tailoring Gnus to your needs. * Troubleshooting:: What you might try if things do not work. * The End:: Farewell and goodbye. * Appendix:: Technical stuff for technical people. * Index:: Variable, function and concept index. * Key Index:: Key Index.  File: gnus, Node: History, Next: Terminology, Prev: Top, Up: Top 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. * Menu: * 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.  File: gnus, Node: Why?, Next: Compatibility, Up: History 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'.  File: gnus, Node: Compatibility, Next: Conformity, Prev: Why?, Up: History 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. *Note 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.  File: gnus, Node: Conformity, Next: Contributors, Prev: Compatibility, Up: History 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.  File: gnus, Node: Contributors, Next: New Features, Prev: Conformity, Up: History 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 , yup, I'll release it right away no wait, that doesn't work at all , yup, I'll ship that one off right away 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.  File: gnus, Node: New Features, Next: Newest Features, Prev: Contributors, Up: History New Features ============ * The look of all buffers can be changed by setting format-like variables (*note Group Buffer Format::. and *note Summary Buffer Format::.). * Local spool and several NNTP servers can be used at once (*note Foreign Groups::.). * You can combine groups into virtual groups (*note nnvirtual::.). * You can read a number of different mail formats (*note 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 (*note 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 (*note The Active File::.). * Gnus implements a sliding scale of subscribedness to groups (*note Group Levels::.). * You can score articles according to any number of criteria (*note Score Files::.). You can even get Gnus to score articles for you (*note 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 (*note 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 (*note Process/Prefix::.). * You can grep through a subset of groups and create a group from the results (*note nnkiboze::.). * You can list subsets of groups according to, well, anything (*note Listing Groups::.). * You can browse foreign servers and subscribe to groups from those servers (*note Browse Foreign Server::.). * Gnus can fetch articles asynchronously on a second connection to the server (*note Asynchronous Fetching::.). * You can cache articles locally (*note Article Caching::.). * The uudecode functions have been expanded and generalized (*note Decoding Articles::.). * You can still post uuencoded articles, which was a little-known feature of GNUS past (*note Uuencoding & Posting::.). * Fetching parents (and other articles) now actually works without glitches (*note Finding the Parent::.). * Gnus can fetch FAQs to and descriptions of groups (*note Group Information::.). * Digests (and other files) can be used as the basis for groups (*note nndoc::.). * Articles can be highlighted and customized (*note Customizing Articles::.). * All Gnus buffers can be customized in a difficult fashion (*note Windows Configuration::.). * You can click on buttons instead of using the keyboard (*note 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.  File: gnus, Node: Newest Features, Prev: New Features, Up: History 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 `'.  File: gnus, Node: Terminology, Next: Starting Up, Prev: History, Up: Top 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 at the same time. These are groups that use different backends for getting news. "head" The top part of an article, where administration 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 for all the unread articles in the group. Most servers support the News OverView format, which is much smaller and much faster to read 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).  File: gnus, Node: Starting Up, Next: The Group Buffer, Prev: Terminology, Up: Top Starting Gnus ************* If your system administrator has set things up properly, starting Gnus and reading news is extremely easy - you just type `M-x gnus'. If things do not go smoothly at startup, you have to twiddle some variables. * Menu: * Finding the News:: Choosing a method for getting news. * The First Time:: What does Gnus do the first time you start it? * The Server is Down:: How can I read my mail then? * New Groups:: What is Gnus supposed to do with new groups? * Startup Files:: Those pesky startup files - `.newsrc'. * Auto Save:: Recovering from a crash. * The Active File:: Reading the active file over a slow line Takes Time. * Startup Variables:: Other variables you might change.  File: gnus, Node: Finding the News, Next: The First Time, Up: Starting Up Finding the News ================ The `gnus-select-method' variable controls how Gnus finds news. This variable should be a list where the first element says "how" and the second element says "where". This method is is your native method. All groups that are not fetched with this method are foreign groups. For instance, if you want to get your daily dosage of news from the `news.somewhere.edu' NNTP server, you'd say: (setq gnus-select-method '(nntp "news.somewhere.edu")) If you want to read directly from the local spool, say: (setq gnus-select-method '(nnspool "")) If you can use a local spool, you probably should, as it will almost certainly be much faster. If this variable is not set, Gnus will take a look at the `NNTPSERVER' environment variable. If that isn't set either, it will try to use the machine that is running Emacs as an NNTP server. If `gnus-nntp-server' is set, this variable will override `gnus-select-method'. You should therefore set `gnus-nntp-server' to `nil', which is what it is by default. You can also make Gnus prompt you interactively for the name of an NNTP server. If you give a non-numerical prefix to `gnus' (i.e., `C-u M-x gnus'), Gnus will let you choose between the servers in the `gnus-secondary-servers' list (if any). You can also just type in the name of any server you feel like visiting. However, if you use one NNTP server regularly, and are just interested in a couple of groups from a different server, you would be better served by using the `gnus-group-browse-foreign-server' command from the group buffer. It will let you have a look at what groups are available, and you can subscribe to any of the groups you want to. This also makes `.newsrc' maintenance much tidier. *Note Foreign Groups::. A slightly different approach to foreign groups is to set the `gnus-secondary-select-methods' variable. The select methods listed in this variable are in many ways just as native as the `gnus-select-method' server. They will also be queried for active files during startup (if that's required), and new newsgroups that appear on these servers will be subscribed (or not) just as native groups are. For instance, if you use the `nnmbox' backend to read you mail, you would typically set this variable to (setq gnus-secondary-select-methods '((nnmbox "")))  File: gnus, Node: The First Time, Next: The Server is Down, Prev: Finding the News, Up: Starting Up The First Time ============== If no startup files exist, Gnus will try to determine what groups should be subscribed by default. If the variable `gnus-default-subscribed-newsgroups' is set, Gnus will subscribe you to just those groups in that list, leaving the rest killed. Your system administrator should have set this variable to something useful. Since she hasn't, Gnus will just subscribe you to a few randomly picked groups (i.e., `*.newusers'). ("Random" is here defined as "whatever Lars thinks you should read".) You'll also be subscribed to the Gnus documentation group, which should help you with most common problems. If `gnus-default-subscribed-newsgroups' is `t', Gnus will just use the normal functions for handling new groups, and not do anything special.  File: gnus, Node: The Server is Down, Next: New Groups, Prev: The First Time, Up: Starting Up The Server is Down ================== If the default server is down, Gnus will understandably have some problems starting. However, if you have some mail groups in addition to the news groups, you may want to start Gnus anyway. Gnus, being the trusting sort of program, will ask whether to proceed without a native select method if that server can't be contacted. This will happen whether the server doesn't actually exist (i.e., you have given the wrong address) or the server has just momentarily taken ill for some reason or other. If Gnus says "nntp server on can't be opened. Continue?", you do not want to continue unless you have some foreign groups that you want to read. Even if you don't, Gnus will let you continue, but you'll find it difficult to actually do anything in the group buffer. But, hey, that's your problem. Blllrph!  File: gnus, Node: New Groups, Next: Startup Files, Prev: The Server is Down, Up: Starting Up New Groups ========== What Gnus does when it encounters a new group is determined by the `gnus-subscribe-newsgroup-method' variable. This variable should contain a function. Some handy pre-fab values are: `gnus-subscribe-randomly' Subscribe all new groups randomly. `gnus-subscribe-alphabetically' Subscribe all new groups alphabetically. `gnus-subscribe-hierarchically' Subscribe all new groups hierarchically. `gnus-subscribe-interactively' Subscribe new groups interactively. This means that Gnus will ask you about *all* new groups. `gnus-subscribe-zombies' Make all new groups zombies. You can browse the zombies later and either kill them all off properly, or subscribe to them. This is the default. A closely related variable is `gnus-subscribe-hierarchical-interactive'. (That's quite a mouthful.) If this variable is non-`nil', Gnus will ask you in a hierarchical fashion whether to subscribe to new groups or not. Gnus will ask you for each sub-hierarchy whether you want to descend the hierarchy or not. One common way to control which new newsgroups should be subscribed or ignored is to put an "options" line at the start of the `.newsrc' file. Here's an example: options -n !alt.all !rec.all sci.all This line obviously belongs to a serious-minded intellectual scientific person (or she may just be plain old boring), because it says that all groups that have names beginning with `alt' and `rec' should be ignored, and all groups with names beginning with `sci' should be subscribed. Gnus will not use the normal subscription method for subscribing these groups. `gnus-subscribe-options-newsgroup-method' is used instead. This variable defaults to `gnus-subscribe-alphabetically'. If you don't want to mess with your `.newsrc' file, you can just set the two variables `gnus-options-subscribe' and `gnus-options-not-subscribe'. These two variables do exactly the same as the `.newsrc' options -n trick. Both are regexps, and if the the new group matches the first, it will be unconditionally subscribed, and if it matches the latter, it will be ignored. If you are satisfied that you really never want to see any new groups, you could set `gnus-check-new-newsgroups' to `nil'. This will also save you some time at startup. Even if this variable is `nil', you can always subscribe to the new groups just by pressing `U' in the group buffer (*note Group Maintenance::.). Gnus normally determines whether a group is new or not by comparing the list of groups from the active file(s) with the lists of subscribed and dead groups. This isn't a particularly fast method. If `gnus-check-new-newsgroups' is `ask-server', Gnus will ask the server for new groups since the last time. This is both faster & cheaper. This also means that you can get rid of the list of killed groups altogether, so you may set `gnus-save-killed-list' to `nil', which will save time both at startup, at exit, and all over. Saves disk space, too. Why isn't this the default, then? Unfortunately, not all servers support this function. This variable can also be a list of select methods. If so, Gnus will issue an `ask-server' command to each of the select methods, and subscribe them (or not) using the normal methods. This might be handy if you are monitoring a few servers for new groups. A side effect is that startup will take much longer, so you can meditate while waiting. Use the mantra "dingnusdingnusdingnus" to achieve permanent happiness.  File: gnus, Node: Startup Files, Next: Auto Save, Prev: New Groups, Up: Starting Up Startup Files ============= Now, you all know about the `.newsrc' file. All subscription information is traditionally stored in this file. Things got a bit more complicated with GNUS. In addition to keeping the `.newsrc' file updated, it also used a file called `.newsrc.el' for storing all the information that didn't fit into the `.newsrc' file. (Actually, it duplicated everything in the `.newsrc' file.) GNUS would read whichever one of these files that were the most recently saved, which enabled people to swap between GNUS and other newsreaders. That was kinda silly, so Gnus went one better: In addition to the `.newsrc' and `.newsrc.el' files, Gnus also has a file called `.newsrc.eld'. It will read whichever of these files that are most recent, but it will never write a `.newsrc.el' file. You can also turn off writing the `.newsrc' file by setting `gnus-save-newsrc-file' to `nil', which means you can delete the file and save some space, as well as making exit from Gnus faster. However, this will make it impossible to use other newsreaders than Gnus. But hey, who would want to, right? If `gnus-save-killed-list' is `nil', Gnus will not save the list of killed groups to the startup file. This will save both time (when starting and quitting) and space (on disk). It will also means that Gnus has no record of what groups are new or old, so the automatic new groups subscription methods become meaningless. You should always set `gnus-check-new-newsgroups' to `nil' or `ask-server' if you set this variable to `nil' (*note New Groups::.). The `gnus-startup-file' variable says where the startup files are. The default value is `~/.newsrc', with the Gnus (El Dingo) startup file being whatever that one is with a `.eld' appended. `gnus-save-newsrc-hook' is called before saving the `.newsrc' file.  File: gnus, Node: Auto Save, Next: The Active File, Prev: Startup Files, Up: Starting Up Auto Save ========= Whenever you do something that changes the Gnus data (reading articles, catching up, killing/subscribing groups), the change is added to a special "dribble buffer". This buffer is auto-saved the normal Emacs way. If your Emacs should crash before you have saved the `.newsrc' files, all changes you have made can be recovered from this file. If Gnus detects this file at startup, it will ask the user whether to read it. The auto save file is deleted whenever the real startup file is saved. If `gnus-use-dribble-file' is `nil', Gnus won't create and maintain a dribble buffer.  File: gnus, Node: The Active File, Next: Startup Variables, Prev: Auto Save, Up: Starting Up The Active File =============== When Gnus starts, or indeed whenever it tries to determine whether new articles have arrived, it reads the active file. This is a very large file that lists all the active groups and articles on the NNTP server. Before examining the active file, Gnus deletes all lines that match the regexp `gnus-ignored-newsgroups'. This is done primarily to reject any groups with bogus names, but you can use this variable to make Gnus ignore hierarchies you aren't ever interested in. This variable is `nil' by default, and will slow down active file handling somewhat if you set it to anything else. The active file can be rather Huge, so if you have a slow network, you can set `gnus-read-active-file' to `nil' to prevent Gnus from reading the active file. Gnus will try to make do by just getting information on the groups that you actually subscribe to. Note that if you subscribe to lots and lots of groups, setting this variable to `nil' will probably make Gnus slower, not faster. At present, having this variable `nil' will slow Gnus down considerably, unless you read news over a 2400 baud modem. This variable can also have the value `some'. Gnus will then attempt to read active info only on the subscribed groups. On some servers this is quite fast (on sparkling, brand new INN servers that support the `LIST ACTIVE group' command), on others this is not fast at all. In any case, `some' should be faster than `nil', and is certainly faster than `t' over slow lines. If this variable is `nil', Gnus will as for group info in total lock-step, which isn't very fast. If it is `some' and you use an NNTP server, Gnus will pump out commands as fast as it can, and read all the replies in one swoop. This will normally result in better performance, but if the server does not support the aforementioned `LIST ACTIVE group' command, this isn't very nice to the server. In any case, if you use `some' or `nil', you should kill all groups that you aren't interested in.  File: gnus, Node: Startup Variables, Prev: The Active File, Up: Starting Up Startup Variables ================= `gnus-load-hook' A hook that is run while Gnus is being loaded. Note that this hook will normally be run just once in a single Emacs session, no matter how many times you start Gnus. `gnus-startup-hook' A hook that is run after starting up Gnus successfully. `gnus-check-bogus-newsgroups' If non-`nil', Gnus will check for and delete all bogus groups at startup. A "bogus group" is a group that you have in your `.newsrc' file, but doesn't exist on the news server. Checking for bogus groups isn't very quick, so to save time and resources, it's best to leave this option off, and instead do the checking for bogus groups once in a while from the group buffer (*note Group Maintenance::.). `gnus-inhibit-startup-message' If non-`nil', the startup message won't be displayed. That way, your boss might not notice that you are reading news instead of doing your job. `gnus-no-groups-message' Message displayed by Gnus when no groups are available.  File: gnus, Node: The Group Buffer, Next: The Summary Buffer, Prev: Starting Up, Up: Top The Group Buffer **************** The "group buffer" lists all (or parts) of the available groups. It is the first buffer shown when Gnus starts, and will never be killed as long as Gnus is active. * Menu: * Group Buffer Format:: Information listed and how you can change it. * Group Maneuvering:: Commands for moving in the group buffer. * Selecting a Group:: Actually reading news. * Group Subscribing:: Unsubscribing, killing, subscribing. * Group Levels:: Levels? What are those, then? * Marking Groups:: You can mark groups for later processing. * Foreign Groups:: How to create foreign groups. * Group Parameters:: Each group may have different parameters set. * Listing Groups:: Gnus can list various subsets of the groups. * Group Maintenance:: Maintaining a tidy `.newsrc' file. * Browse Foreign Server:: You can browse a server. See what if has to offer. * Exiting Gnus:: Stop reading news and get some work done. * Misc Group Stuff:: Other stuff that you can to do.  File: gnus, Node: Group Buffer Format, Next: Group Maneuvering, Up: The Group Buffer Group Buffer Format =================== The default format of the group buffer is nice and dull, but you can make it as exciting and ugly as you feel like. Here's a couple of example group lines: 25: news.announce.newusers * 0: alt.fan.andrea-dworkin Quite simple, huh? You can see that there are 25 unread articles in `news.announce.newusers'. There are no unread articles, but some ticked articles, in `alt.fan.andrea-dworkin' (see that little asterisk at the beginning of the line?) You can fuck that up to your heart's delight by fiddling with the `gnus-group-line-format' variable. This variable works along the lines of a `format' specification, which is pretty much the same as a `printf' specifications, for those of you who use (feh!) C. In addition to the normal "padding" specs that `format' supports (eg. `%7d'), specifications like `%7,12s' are allowed. A spec of this type means that the field will be at least 7 characters long, and never more that 12 characters long. The default value that produced those lines above is `"%M%S%5y: %(%g%)\n"'. There should always be a colon on the line; the cursor always moves to the colon after performing an operation. Nothing else is required - not even the group name. All displayed text is just window dressing, and is never examined by Gnus. Gnus stores all real information it needs using text properties. (Note that if you make a really strange, wonderful, spreadsheet-like layout, everybody will believe you are hard at work with the accounting instead of wasting time reading news.) Here's a list of all available format characters: `M' Only marked articles. `S' Whether the group is subscribed. `L' Level of subscribedness. `N' Number of unread articles. `I' Number of dormant articles. `T' Number of ticked articles. `R' Number of read articles. `t' Total number of articles. `y' Number of unread, unticked, non-dormant articles. `i' Number of ticked and dormant articles. `g' Full group name. `G' Group name. `D' Newsgroup description. `o' Moderated. `O' Moderated. `s' Select method. `n' Select from where. `z' A string that looks like `<%s:%n>' if a foreign select method is used. `u' User defined specifier. The next character in the format string should be a letter. GNUS will call the function `gnus-user-format-function-'`X', where `X' is the letter following `%u'. The function will be passed the current headers as argument. The function should return a string, which will be inserted into the buffer just like information from any other specifier. All the "number-of" specs will be filled with an asterisk (`*') if no info is available - for instance, if it is a non-activated foreign group, or a bogus (or semi-bogus) native group. The mode line can be changed by setting (`gnus-group-mode-line-format'). It doesn't understand that many format specifiers: `S' Default news server. `M' Default select method.  File: gnus, Node: Group Maneuvering, Next: Selecting a Group, Prev: Group Buffer Format, Up: The Group Buffer Group Maneuvering ================= All movement commands understand the numeric prefix and will behave as expected, hopefully. `n' Go to the next group that has unread articles (`gnus-group-next-unread-group'). `p' `DEL' Go to the previous group group that has unread articles (`gnus-group-prev-unread-group'). `N' Go to the next group (`gnus-group-next-group'). `P' Go to the previous group (`gnus-group-prev-group'). `M-p' Go to the next unread group on the same level (or lower) (`gnus-group-next-unread-group-same-level'). `M-n' Go to the previous unread group on the same level (or lower) (`gnus-group-prev-unread-group-same-level'). Three commands for jumping to groups: `j' Jump to a group (and make it visible if it isn't already) (`gnus-group-jump-to-group'). Killed groups can be jumped to, just like living groups. `,' Jump to the unread group with the lowest level (`gnus-group-best-unread-group'). `.' Jump to the first group with unread articles (`gnus-group-first-unread-group'). If `gnus-group-goto-unread' is `nil', all the movement commands will move to the next group, not the next unread group. Even the commands that say they move to the next unread group.  File: gnus, Node: Selecting a Group, Next: Group Subscribing, Prev: Group Maneuvering, Up: The Group Buffer Selecting a Group ================= `SPACE' Select the current group, switch to the summary buffer and display the first unread article (`gnus-group-read-group'). If there are no unread articles in the group, or if you give a non-numerical prefix to this command, Gnus will offer to fetch all the old articles in this group from the server. If you give a numerical prefix N, Gnus will fetch N number of articles. If N is positive, fetch the N newest articles, if N is negative, fetch the ABS(N) oldest articles. `RET' Select the current group and switch to the summary buffer (`gnus-group-select-group'). Takes the same arguments as `gnus-group-read-group' - the only difference is that this command does not display the first unread article automatically upon group entry. `c' Mark all unticked articles in this group as read (`gnus-group-catchup-current'). `C' Mark all articles in this group, even the ticked ones, as read (`gnus-group-catchup-current-all'). The `gnus-large-newsgroup' variable says what Gnus should consider to be a big group. If the group has more unread articles than this, Gnus will query the user before entering the group. The user can then specify how many articles should be fetched from the server. If the user specifies a negative number (`-n'), the `n' oldest articles will be fetched. If it is positive, the `n' articles that have arrived most recently will be fetched. If `gnus-auto-select-first' is non-`nil', the first unread article in the group will be displayed when you enter the group. If you want to prevent automatic selection in some group (say, in a binary group with Huge articles) you can set this variable to `nil' in `gnus-select-group-hook', which is called when a group is selected. If you are using a threaded summary display, you can sort the threads by setting `gnus-thread-sort-functions', which is a list of functions. By default, sorting is done on article numbers. Ready-made sorting functions include `gnus-thread-sort-by-number', `gnus-thread-sort-by-author', `gnus-thread-sort-by-subject', `gnus-thread-sort-by-date', `gnus-thread-sort-by-score', `gnus-thread-sort-by-total-score'. Each function takes two threads and return non-`nil' if the first thread should be sorted before the other. If you use more than one function, the primary sort key should be the last function in the list. If you would like to sort by score, then by subject, and finally by date, you could do something like: (setq gnus-thread-sort-functions '(gnus-thread-sort-by-date gnus-thread-sort-by-subject gnus-thread-sort-by-score)) The function in the `gnus-thread-score-function' variable (default `+') is used for calculating the total score of a thread. Useful functions might be `max', `min', or squared means, or whatever tickles you fancy.  File: gnus, Node: Group Subscribing, Next: Group Levels, Prev: Selecting a Group, Up: The Group Buffer Group Subscribing ================= `S t' `u' Toggle subscription to the current group (`gnus-group-unsubscribe-current-group'). `S s' `U' Prompt for a group to subscribe, and then subscribe it. If it was subscribed already, unsubscribe it instead (`gnus-group-unsubscribe-group'). `S k' `C-k' Kill the current group (`gnus-group-kill-group'). `S y' `C-y' Yank the last killed group (`gnus-group-yank-group'). `S w' `C-w' Kill all groups in the region (`gnus-group-kill-region'). `S z' Kill all zombie groups (`gnus-group-kill-all-zombies').  File: gnus, Node: Group Levels, Next: Marking Groups, Prev: Group Subscribing, Up: The Group Buffer Group Levels ============ All groups have a level of "subscribedness". For instance, if a group is on level 2, it is more subscribed than a group on level 5. You can ask Gnus to just list groups on a given level or lower (*note Listing Groups::.), or to just check for new articles in groups on a given level or lower (*note Misc Group Stuff::.). `S l' Set the level of the current group. If a numeric prefix is given, the next N groups will have their levels set. The user will be prompted for a level. Gnus considers groups on between levels 1 and `gnus-level-subscribed' (inclusive) to be subscribed, `gnus-level-subscribed' (exclusive) and `gnus-level-unsubscribed' (inclusive) to be unsubscribed, `gnus-level-zombie' to be zombies (walking dead) and `gnus-level-killed' to be killed, completely dead. Gnus treats subscribed and unsubscribed groups exactly the same, but zombie and killed groups have no information on what articles you have read, etc, stored. This distinction between dead and living groups isn't done because it is nice or clever, it is done purely for reasons of efficiency. It is recommended that you keep all your mail groups (if any) on quite low levels (eg. 1 or 2). If you want to play with the level variables, you should show some care. Set them once, and don't touch them ever again. Better yet, don't touch them at all unless you know exactly what you're doing. Two closely related variables are `gnus-level-default-subscribed' and `gnus-level-default-unsubscribed', which are the levels that new groups will be put on if they are (un)subscribed. These two variables should, of course, be inside the relevant legal ranges. If `gnus-keep-same-level' is non-`nil', some movement commands will only move to groups that are of the same level (or lower). In particular, going from the last article in one group to the next group will go to the next group of the same level (or lower). This might be handy if you want to read the most important groups before you read the rest. All groups with a level less than or equal to `gnus-group-default-list-level' will be listed in the group buffer by default. If `gnus-group-use-permament-levels' is non-`nil', once you give a level prefix to `g' or `l', all subsequent commands will use this level as the "work" level.  File: gnus, Node: Marking Groups, Next: Foreign Groups, Prev: Group Levels, Up: The Group Buffer Marking Groups ============== If you want to perform some action on several groups, and they appear subsequently in the group buffer, you would normally just give a numerical prefix to the command. Most group commands will then do your bidding on those groups. However, if the groups are not in sequential order, you can still perform an action on several groups. You simply mark the groups first, and then execute the command. `#' `M m' Set the mark on the current group (`gnus-group-mark-group'). `M-#' `< u' Remove the mark from the current group (`gnus-group-unmark-group'). `M w' Mark all groups between point and mark (`gnus-group-mark-region').