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.
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:
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:
All movement commands understand the numeric prefix and will behave as expected, hopefully.
gnus-group-next-unread-group).
gnus-group-prev-unread-group).
gnus-group-next-group).
gnus-group-prev-group).
gnus-group-next-unread-group-same-level).
gnus-group-prev-unread-group-same-level).
Three commands for jumping to groups:
gnus-group-jump-to-group). Killed groups can be jumped to, just
like living groups.
gnus-group-best-unread-group).
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.
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.
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.
gnus-group-catchup-current).
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.
gnus-group-unsubscribe-current-group).
gnus-group-unsubscribe-group).
gnus-group-kill-group).
gnus-group-yank-group).
gnus-group-kill-region).
gnus-group-kill-all-zombies).
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 (see section Listing Groups), or to just check for new articles in groups on a given level or lower (see section Misc Group Stuff).
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.
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.
gnus-group-mark-group).
gnus-group-unmark-group).
gnus-group-mark-region).
A foreign group is a group that is not read by the usual (or default) means. It could be, for instance, a group from a different NNTP server, it could be a virtual group, or it could be your own personal mail group.
A foreign group (or any group, really) is specified by a name and
a select method. To take the latter first, a select method is a
list where the first element says what backend to use (eg. nntp,
nnspool, nnml) and the second element is the server
name. There may be additional elements in the select method, where the
value may have special meaning for the backend in question.
One could say that a select method defines a virtual server - so we do just that (see section The Server Buffer).
The name of the group is the name the backend will recognize the group as.
For instance, the group `soc.motss' on the NNTP server
`some.where.edu' will have the name `soc.motss' and select
method (nntp "some.where.edu"). Gnus will call this group, in
all circumstances, `nntp+some.where.edu:soc.motss', even though the
nntp backend just knows this group as `soc.motss'.
Here are some commands for making and editing general foreign groups, and some commands to ease the creation of some special-purpose groups:
gnus-group-make-group). Gnus will prompt you
for a name, a method and possibly an address. For an easier way
to subscribe to NNTP groups, See section Browse Foreign Server.
gnus-group-edit-group-method).
gnus-group-edit-group-parameters).
gnus-group-edit-group).
gnus-group-make-directory-group).
gnus-group-make-help-group).
gnus-group-make-archive-group). By
default a group pointing to the most recent articles will be created
(gnus-group-recent-archibe-directory), but given a prefix, a full
group will be created from from gnus-group-archive-directory.
gnus-group-make-kiboze-group).
nneething backend (gnus-group-enter-directory).
gnus-group-make-doc-group). You will be prompted for a file
name and a file type. Currently supported types are babyl,
mbox and digest.
nnvirtual group
(gnus-group-make-empty-virtual).
nnvirtual group
(gnus-group-add-to-virtual). Uses the process/prefix convention.
The different methods all have their peculiarities, of course.
If the gnus-activate-foreign-newsgroups is a positive number,
Gnus will check all foreign groups with this level or lower at startup.
This might take quite a while, especially if you subscribe to lots of
groups from different NNTP servers. It is nil by default,
which means that you won't be told whether there are new articles in
these groups. How many unread articles there are will be determined
when, or if, you decide to enter them. You can also activate any group
with M-g to see how many unread articles there are.
Subscribing to a foreign group from an NNTP server is rather easy.
You just specify nntp as method and the address of the NNTP
server as the, uhm, address.
If the NNTP server is located at a non-standard port, setting the third element of the select method to this port number should allow you to connect to the right port. You'll have to edit the group info for that (see section Foreign Groups).
The name of the foreign group can be the same as a native group. In fact, you can subscribe to the same group from as many different servers you feel like. There will be no name collisions.
The following variables can be used to create a virtual nntp
server:
nntp-server-opened-hook
nntp-server-opened-hook is run after a connection has been made.
It can be used to send commands to the NNTP server after it has
been contacted. By default is sends the command `MODE READER' to
the server with the nntp-send-mode-reader function. Another
popular function is nntp-send-authinfo, which will prompt you for
an NNTP password and stuff.
nntp-maximum-request
head commands. To
speed things up, the backend sends lots of these commands without
waiting for reply, and then reads all the replies. This is controlled
by the nntp-maximum-request variable, and is 400 by default. If
your network is buggy, you should set this to 1.
nntp-connection-timeout
nntp groups that you connect to
regularly, you're sure to have problems with NNTP servers not
responding properly, or being too loaded to reply within reasonable
time. This is can lead to awkward problems, which can be helped
somewhat by setting nntp-connection-timeout. This is an integer
that says how many seconds the nntp backend should wait for a
connection before giving up. If it is nil, which is the default,
no timeouts are done.
nntp-server-hook
nntp-address
nntp-port-number
nntp-open-network-stream
connect function.
nntp-buggy-select
nil if your select routine is buggy.
nntp-nov-is-evil
t, but nntp usually checks whether NOV
can be used automatically.
nntp-xover-commands
("XOVER"
"XOVERVIEW").
nntp-nov-gap
nntp normally sends just one big request for NOV lines to
the server. The server responds with one huge list of lines. However,
if you have read articles 2-5000 in the group, and only want to read
article 1 and 5001, that means that nntp will fetch 4999 NOV
lines that you do not want, and will not use. This variable says how
big a gap between two consecutive articles is allowed to be before the
XOVER request is split into several request. Note that if your
network is fast, setting this variable to a really small number means
that fetching will probably be slower. If this variable is nil,
nntp will never split requests.
nntp-prepare-server-hook
nntp-async-number
t, nntp will pre-fetch all the articles
that it can without bound. If it is nil, no pre-fetching will be
made.
Subscribing to a foreign group from the local spool is extremely easy, and might be useful, for instance, to speed up reading groups like `alt.binaries.pictures.furniture'.
Anyways, you just specify nnspool as the method and `""' (or
anything else) as the address.
If you have access to a local spool, you should probably use that as the native select method (see section Finding the News).
nnspool-inews-program
nnspool-inews-switches
nnspool-spool-directory
nnspool-nov-directory
nnspool-lib-dir
nnspool-active-file
nnspool-newsgroups-file
nnspool-history-file
nnspool-active-times-file
nnspool-nov-is-evil
nil, nnspool won't try to use any NOV files
that it finds.
nnspool-sift-nov-with-sed
nil, which is the default, use sed to get the
relevant portion from the overview file. If nil, nnspool will
load the entire file into a buffer and process it there.
An nnvirtual group is really nothing more than a collection of other groups.
For instance, if you are tired of reading many small group, you can put them all in one big group, and then grow tired of reading one big, unwieldy group. The joys of computing!
You specify nnvirtual as the method. The address should be a
regexp to match component groups.
All marks in the virtual group will stick to the articles in the component groups. So if you tick an article in a virtual group, the article will also be ticked in the component group from whence it came. (And vice versa - marks from the component groups will also be shown in the virtual group.)
Here's an example nnvirtual method that collects all Andrea Dworkin newsgroups into one, big, happy newsgroup:
(nnvirtual "^alt\\.fan\\.andrea-dworkin$\\|^rec\\.dworkin.*")
The component groups can be native or foreign; everything should work smoothly, but if your computer explodes, it was probably my fault.
Collecting the same group from several servers might actually be a good idea if users have set the Distribution header to limit distribution. If you would like to read `soc.motss' both from a server in Japan and a server in Norway, you could use the following as the group regexp:
"^nntp+some.server.jp:soc.motss$\\|^nntp+some.server.no:soc.motss$"
This should work kinda smoothly - all articles from both groups should end up in this one, and there should be no duplicates. Threading (and the rest) will still work as usual, but there might be problems with the sequence of articles. Sorting on date might be an option here (see section Selecting a Group.
One limitation, however - all groups that are included in a virtual group has to be alive (i.e., subscribed or unsubscribed). Killed or zombie groups can't be component groups for nnvirtual groups.
Kibozing is defined by OED as "grepping through (parts of) the news feed". nnkiboze is a backend that will do this for you. Oh joy! Now you can grind any NNTP server down to a halt with useless requests! Oh happiness!
The address field of the nnkiboze method is, as with nnvirtual, a regexp to match groups to be "included" in the nnkiboze group. There most similarities between nnkiboze and nnvirtual ends.
In addition to this regexp detailing component groups, an nnkiboze group must have a score file to say what articles that are to be included in the group (see section Score Files).
You must run M-x nnkiboze-generate-groups after creating the nnkiboze groups you want to have. This command will take time. Lots of time. Oodles and oodles of time. Gnus has to fetch the headers from all the articles in all the components groups and run them through the scoring process to determine if there are any articles in the groups that are to be part of the nnkiboze groups.
Please limit the number of component groups by using restrictive regexps. Otherwise your sysadmin may become annoyed with you, and the NNTP site may throw you off and never let you back in again. Stranger things have happened.
nnkiboze component groups do not have to be alive - they can be dead, and they can be foreign. No restrictions.
The generation of an nnkiboze group means writing two files in
nnkiboze-directory, which is `~/News/' by default. One
contains the NOV header lines for all the articles in the group,
and the other is an additional `.newsrc' file to store information
on what groups that have been searched through to find component
articles.
Articles that are marked as read in the nnkiboze group will have their NOV lines removed from the NOV file.
If you have a directory that has lots of articles in separate files in it, you might treat it as a newsgroup. The files have to have numerical names, of course.
This might be an opportune moment to mention ange-ftp, that most
wonderful of all wonderful Emacs packages. When I wrote nndir, I
didn't think much about it - a backend to read directories. Big deal.
ange-ftp changes that picture dramatically. For instance, if you
enter `"/ftp@sina.tcamc.uh.edu:/pub/emacs/ding-list/"' as the the
directory name, ange-ftp will actually allow you to read this directory
over at `sina' as a newsgroup. Distributed news ahoy!
nndir will use NOV files if they are present.
nndir is a "read-only" backend - you can't delete or expire
articles with this method. You can use nnmh or nnml for
whatever you use nndir for, so you could switch to any of those
methods if you feel the need to have a non-read-only nndir.
From the nndir backend (which reads a single spool-like
directory), it's just a hop and a skip to nneething, which
pretends that any random directory is a newsgroup. Strange, but true.
When nneething is presented with a directory, it will scan this
directory and assign article numbers to each file. When you enter such a
group, nneething must create "headers" that Gnus can use. After
all, Gnus is a newsreader, in case you're forgetting. nneething
does this in a two-step process. First, it snoops each file in question.
If the file looks like an article (i.e., the first few lines look like
headers), it will use this as the head. If this is just some random file
without a head (eg. a C source file), nneething will cobble up a
header out of thin air. It will use file ownership, name and date and do
whatever it can with these elements.
All this should happen automatically for you, and you will be presented with something that looks very much like a newsgroup. Totally like a newsgroup, to be precise. If you select an article, it will be displayed in the article buffer, just as usual.
If you select a line that represents a directory, Gnus will pop you into
a new summary buffer for this nneething group. And so on. You can
traverse the entire disk this way, if you feel like, but remember that
Gnus is not dired, really, and does not intend to be, either.
There are two overall modes to this action - ephemeral or solid. When
doing the ephemeral thing (i.e., G D from the group buffer), Gnus
will not store information on what files you have read, and what files
are new, and so on. If you create a solid nneething group the
normal way with G m, Gnus will store a mapping table between
article numbers and file names, and you can treat this group like any
other groups. When you activate a solid nneething group, you will
be told how many unread articles it contains, etc., etc.
Some variables:
nneething-map-file-directory
nneething groups will be stored
in this directory, which defaults to `~/.nneething/'.
nneething-exclude-files
nneething-map-file
nndoc is a cute little thing that will let you read a single file as a
newsgroup. Currently supported file types are babyl, mbox
and digest.
nndoc will not try to change the file or insert any extra headers into it - it will simply, like, let you use the file as the basis for a group. And that's it.
Virtual server variables:
nndoc-article-type
mbox, babyl or digest.
Reading mail with a newsreader - isn't that just plain WeIrD? But of course.
Gnus will read the mail spool when you activate a mail group. The mail file is first copied to your home directory. What happens after that depends on what format you want to store your mail in.
The mail backends all call nnmail-read-incoming-hook after
reading new mail. You can use this hook to notify any mail watch
programs, if you want to.
nnmail-spool-file says where to look for new mail. If this
variable is nil, the mail backends will never attempt to fetch
mail by themselves. It is quite likely that Gnus supports POP-mail.
Set this variable to begin with the string `po:', and everything
should go smoothly, even though I have never tested this.
If nnmail-use-procmail is non-nil, the mail backends will
look in nnmail-procmail-directory for incoming mail. All the
files in that directory that have names ending in
gnus-procmail-suffix will be considered incoming mailboxes, and
will be searched for new mail.
nnmail-prepare-incoming-hook is run in a buffer that holds all
the new incoming mail, and can be used for, well, anything, really.
nnmail-tmp-directory says where to move the incoming mail to
while processing it. This is usually done in the same directory that
the mail backend inhabits (i.e., `~/Mail/'), but if this variable is
non-nil, it will be used instead.
nnmail-movemail-program is executed to move mail from the user's
inbox to her home directory. The default is `"movemail"'.
If nnmail-delete-incoming is non-nil, the mail backends
will delete the temporary incoming file after splitting mail into the
proper groups. This is nil by default for reasons of security.
If you are a member of a couple of mailing list, you will sometime
receive two copies of the same mail. This can be quite annoying, so
nnmail checks for and discards any duplicates it might find. To
do this, it keeps a cache of old Message-IDs -
nnmail-message-id-cache-file, which is `~/.nnmail-cache' by
default. The approximate maximum number of Message-IDs stored
there is controlled by the nnmail-message-id-cache-length
variable, which is 1000 by default. (So 1000 Message-IDs will be
stored.) If all this sounds scary to you, you can set
nnmail-delete-duplicates to nil (which is what it is by
default), and nnmail won't do any duplicate checking.
Here's a neat feature: If you know that the recipient reads her mail
with Gnus, and that she has nnmail-delete-duplicates set to
t, you can send her as many insults as you like, just by using a
Message-ID of a mail that you know that she's already received.
Think of all the fun! She'll never see any of it! Whee!
Gnus gives you all the opportunity you could possibly want for shooting yourself in the foot. Let's say you create a group that will contain all the mail you get from your boss. And then you accidentally unsubscribe from the group. Gnus will still put all the mail from your boss in the unsubscribed group, and so, when your boss mails you "Have that report ready by Monday or you're fired!", you'll never see it and, come Tuesday, you'll still believe that you're gainfully employed while you really should be out collecting empty bottles to save up for next month's rent money.
You can make Gnus read your personal, private, secret mail.
You should first set gnus-secondary-select-methods to, for
instance, ((nnmbox "")). When you start up Gnus, Gnus will ask
this backend for what groups it carries (`mail.misc' by default)
and subscribe it the normal way. (Which means you may have to look for
it among the zombie groups, I guess, all depending on your
gnus-subscribe-newsgroup-method variable.)
Then you should set the variable nnmail-split-methods to specify
how the incoming mail is to be split into groups.
(setq nnmail-split-methods
'(("mail.junk" "^From:.*Lars Ingebrigtsen")
("mail.crazy" "^Subject:.*die\\|^Organization:.*flabby")
("mail.other" "")))
This variable is a list of lists, where the first element of each of these lists is the name of the mail group (they do not have to be called something beginning with `mail', by the way), and the second element is a regular expression used on the header of each mail to determine if it belongs in this mail group.
The second element can also be a function. In that case, it will be
called narrowed to the headers with the first element of the rule as the
argument. It should return a non-nil value if it thinks that the
mail belongs in that group.
The last of these groups should always be a general one, and the regular expression should always be `""' so that it matches any mails that haven't been matched by any of the other regexps.
If you like to tinker with this yourself, you can set this variable to a function of your choice. This function will be called without any arguments in a buffer narrowed to the headers of an incoming mail message. The function should return a list of groups names that it thinks should carry this mail message.
The mail backends all support cross-posting. If several regexps match,
the mail will be "cross-posted" to all those groups.
nnmail-crosspost says whether to use this mechanism or not. Note
that no articles are crossposted to the general (`""') group.
If the rather simple, standard method for specifying how to split mail
doesn't allow you to do what you want, you can set
nnmail-split-methods to nnmail-split-fancy. Then you can
play with the nnmail-split-fancy variable.
Let's look at an example value of this variable first:
;; Messages from the mailer daemon are not crossposted to any of
;; the ordinary groups. Warnings are put in a separate group
;; from real errors.
(| ("from" mail (| ("subject" "warn.*" "mail.warning")
"mail.misc"))
;; Non-error messages are crossposted to all relevant
;; groups, but we don't crosspost between the group for the
;; (ding) list and the group for other (ding) related mail.
(& (| (any "ding@ifi\\.uio\\.no" "ding.list")
("subject" "ding" "ding.misc"))
;; Other mailing lists...
(any "procmail@informatik\\.rwth-aachen\\.de" "procmail.list")
(any "SmartList@informatik\\.rwth-aachen\\.de" "SmartList.list")
;; People...
(any "larsi@ifi\\.uio\\.no" "people.Lars Magne Ingebrigtsen"))
;; Unmatched mail goes to the catch all group.
"misc.misc"))")
This variable has the format of a split. A split is a (possibly) recursive structure where each split may contain other splits. Here are the four possible split syntaxes:
| (vertical
bar), then process each SPLIT until one of them matches. A SPLIT is
said to match if it will cause the mail message to be stored in one or
more groups.
&, then process
all SPLITs in the list.
In these splits, FIELD must match a complete field name. VALUE must
match a complete word according to the fundamental mode syntax table.
You can use .* in the regexps to match partial field names or
words.
FIELD and VALUE can also be lisp symbols, in that case they are expanded
as specified by the variable nnmail-split-abbrev-alist. This is
an alist of cons cells, where the car of the cells contains the key, and
the cdr contains a string.
Many people use procmail to split incoming mail into groups. If
you do that, you should set nnmail-spool-file to procmail
to ensure that the mail backends never ever try to fetch mail by
themselves.
This also means that you probably don't want to set
nnmail-split-methods either, which has some, perhaps, unexpected
side effects.
When a mail backend is queried for what groups it carries, it replies
with the contents of that variable, along with any groups it has figured
out that it carries by other means. None of the backends (except
nnmh) actually go out to the disk and check what groups actually
exist. (It's not trivial to distinguish between what the user thinks is
a basis for a newsgroup and what is just a plain old file or directory.)
This means that you have to tell Gnus (and the backends) what groups exist by hand.
Let's take the nnmh backend as an example.
The folders are located in nnmh-directory, say, `~/Mail/'.
There are three folders, `foo', `bar' and `mail.baz'.
Go to the group buffer and type G m. When prompted, answer `foo' for the name and `nnmh' for the method. Repeat twice for the two other groups, `bar' and `mail.baz'. Be sure to include all your mail groups.
That's it. You are now set to read your mail. An active file for this method will be created automatically.
If you use nnfolder or any other backend that store more than a
single article in each file, you should never have procmail add mails to
the file that Gnus sees. Instead, procmail should put all incoming mail
in nnmail-procmail-directory. To arrive at the file name to put
the incoming mail in, append nnmail-procmail-suffix to the group
name. The mail backends will read the mail from these files.
When Gnus reads a file called `mail.misc.spool', this mail will be
put in the mail.misc, as one would expect. However, if you want
Gnus to split the mail the normal way, you could set
nnmail-resplit-incoming to t.
If you use procmail to split things directory into an nnmh
directory (which you shouldn't do), you should set
nnmail-keep-last-article to non-nil to prevent Gnus from
ever expiring the final article in a mail newsgroup. This is quite,
quite important.
Traditional mail readers have a tendency to remove mail articles when you mark them as read, in some way. Gnus takes a fundamentally different approach to mail reading.
Gnus basically considers mail just to be news that has been received in a rather peculiar manner. It does not think that it has the power to actually change the mail, or delete any mail messages. If you enter a mail group, and mark articles as "read", or kill them in some other fashion, the mail articles will still exist on the system. I repeat: Gnus will not delete your old, read mail. Unless you ask it to, of course.
To make Gnus get rid of your unwanted mail, you have to mark the articles as expirable. This does not mean that the articles will disappear right away, however. In general, a mail article will be deleted from your system if, 1) it is marked as expirable, AND 2) it is more than one week old. If you do not mark an article as expirable, it will remain on your system until hell freezes over. This bears repeating one more time, with some spurious capitalizations: IF you do NOT mark articles as EXPIRABLE, Gnus will NEVER delete those ARTICLES.
You do not have to mark articles as expirable by hand. Groups that
match the regular expression gnus-auto-expirable-newsgroups will
have all articles that you read marked as expirable automatically. All
articles that are marked as expirable have an `E' in the first
column in the summary buffer.
Let's say you subscribe to a couple of mailing lists, and you want the articles you have read to disappear after a while:
(setq gnus-auto-expirable-newsgroups
"mail.nonsense-list\\|mail.nice-list")
Another way to have auto-expiry happen is to have the element
auto-expire in the select method of the group.
The nnmail-expiry-wait variable supplies the default time an
expirable article has to live. The default is seven days.
Gnus also supplies a function that lets you fine-tune how long articles are to live, based on what group they are in. Let's say you want to have one month expiry period in the `mail.private' group, a one day expiry period in the `mail.junk' group, and a six day expiry period everywhere else:
(setq nnmail-expiry-wait-function
(lambda (group)
(cond ((string= group "mail.private")
31)
((string= group "mail.junk")
1)
(t
6))))
If nnmail-keep-last-article is non-nil, Gnus will never
expire the final article in a mail newsgroup. This is to make life
easier for procmail users.
By the way, that line up there about Gnus never expiring non-expirable
articles is a lie. If you put total-expire in the group
parameters, articles will not be marked as expirable, but all read
articles will be put through the expiry process. Use with extreme
caution.
Note that at present, Gnus will not actually delete any expirable articles automatically. You have to enter one of the expiry functions (eg. `C-c M-c-x' in the group buffer) to actually run articles through the expiry process. Or you can add a call to the expiry function in the group exit hook. Gnus will probably do all this automatically in the future.
If you start using any of the mail backends, they have the annoying habit of assuming that you want to read mail with them. This might not be unreasonable, but it might not be what you want.
If you set nnmail-spool-file to nil, none of the backends
will ever attempt to read incoming mail, which should help.
This might be too much, if, for instance, you are reading mail quite
happily with nnml and just want to peek at some old RMAIL
file you have stashed away with nnbabyl. All backends have
variables called backend-get-new-mail. If you want to disable
the nnbabyl mail reading, you edit the virtual server for the
group to have a setting where nnbabyl-get-new-mail to nil.
All the mail backends will call nn*-prepare-save-mail-hook
narrowed to the article to be saved before saving it when reading
incoming mail.
The nnmbox backend will use the standard Un*x mbox file to store
mail. nnmbox will add extra headers to each mail article to say
which group it belongs in.
Virtual server settings:
nnmbox-mbox-file
nnmbox-active-file
nnmbox-get-new-mail
nil, nnmbox will read incoming mail and split it
into groups.
The nnbabyl backend will use a babyl mail box (aka. rmail
mbox) to store mail. nnbabyl will add extra headers to each mail
article to say which group it belongs in.
Virtual server settings:
nnbabyl-mbox-file
nnbabyl-active-file
nnbabyl-get-new-mail
nil, nnbabyl will read incoming mail.
The nnml spool mail format isn't compatible with any other known format. It should be used with some caution.
If you use this backend, Gnus will split all incoming mail into files;
one file for each mail, and put the articles into the correct
directories under the directory specified by the nnml-directory
variable. The default value is `~/Mail/'.
You do not have to create any directories beforehand; Gnus will take care of all that.
If you have a strict limit as to how many files you are allowed to store in your account, you should not use this backend. As each mail gets its own file, you might very well occupy thousands of inodes within a few weeks. If this is no problem for you, and it isn't a problem for you having your friendly systems administrator walking around, madly, shouting "Who is eating all my inodes?! Who? Who!?!", then you should know that this is probably the fastest format to use. You do not have to trudge through a big mbox file just to read your new mail.
nnml is probably the slowest backend when it comes to article
splitting. It has to create lots of files, and it also generates
NOV databases for the incoming mails. This makes is the fastest
backend when it comes to reading mail.
Virtual server settings:
nnml-directory
nnml directories will be placed under this directory.
nnml-active-file
nnml server.
nnml-newsgroups-file
nnml group description file.
nnml-get-new-mail
nil, nnml will read incoming mail.
nnml-nov-is-evil
nil, this backend will ignore any NOV files.
nnml-nov-file-name
If your nnml groups and NOV files get totally out of whack,
you can do a complete update by typing M-x
nnml-generate-nov-databases. This command will trawl through the
entire nnml hierarchy, looking at each and every article, so it
might take a while to complete.
nnmh is just like nnml, except that is doesn't generate
NOV databases and it doesn't keep an active file. This makes
nnmh a much slower backend than nnml, but it also
makes it easier to write procmail scripts for.
Virtual server settings:
nnmh-directory
nnmh directories will be located under this directory.
nnmh-get-new-mail
nil, nnmh will read incoming mail.
nnmh-be-safe
nil, nnmh will go to ridiculous lengths to make
sure that the articles in the folder is actually what Gnus think they
are. It will check date stamps, and stat everything in sight, so
setting this to t will mean a serious slow-down. If you never
use anything by Gnus to read the nnmh articles, you do not have to set
this variable to t.
nnfolder is a backend for storing each mail group in a separate
file. Each file is in the standard Un*x mbox format. nnfolder
will add extra headers to keep track of article numbers and arrival
dates.
Virtual server settings:
nnfolder-directory
nnfolder mail boxes will be stored under this directory.
nnfolder-active-file
nnfolder-newsgroups-file
nnfolder-get-new-mail
nil, nnfolder will read incoming mail.
Gnus stores all information on a group in a list that is usually known as the group info. This list has from three to six elements. Here's an example info.
("nnml:mail.ding" 3 ((1 . 232) 244 (256 . 270)) ((tick 246 249))
(nnml "private") ((to-address . "ding@ifi.uio.no")))
The first element is the group name, as Gnus knows the group, anyway. The second element is the subscription level, which normally is a small integer. The third element is a list of ranges of read articles. The fourth element is a list of lists of article marks of various kinds. The fifth element is the select method (or virtual server, if you like). The sixth element is a list of group parameters, which is what this section is about.
Any of the last three elements may be missing if they are not required. In fact, the vast majority of groups will normally only have the first three elements, which saves quite a lot of cons cells.
At present, there's not much you can put in the group parameters list:
to-address
to-group
(to-group
. "some.group.name"), all posts will be sent to that groups.
auto-expire
total-expire
If you want to change the group parameters (or anything else of the group info) you can use the G E to edit enter a buffer where you can edit the group info.
You usually don't want to edit the entire group info, so you'd be better off using the G p command to just edit the group parameters.
These commands all list various slices of the groups that are available.
gnus-group-list-groups). If the numeric prefix is used, this
command will list only groups of level ARG and lower. By default, it
only lists groups of level five or lower (i.e., just subscribed groups).
gnus-group-list-all-groups). If the numeric prefix is used,
this command will list only groups of level ARG and lower. By default,
it lists groups of level seven or lower (i.e., just subscribed and
unsubscribed groups).
gnus-group-list-killed).
gnus-group-list-zombies).
gnus-group-list-matching).
gnus-group-list-all-matching).
gnus-group-check-bogus-groups).
gnus-find-new-newsgroups).
gnus-group-expire-articles).
gnus-group-expire-all-groups).
gnus-group-sort-function variable
(gnus-group-sort-groups). Available sorting functions include
gnus-group-sort-by-alphabet (the default),
gnus-group-sort-by-unread and gnus-group-sort-by-level.
gnus-group-browse-foreign-server).
A new buffer with a list of available groups will appear. This buffer
will be use the gnus-browse-server-mode. This buffer looks a bit
(well, a lot) like a normal group buffer, but with one major difference
- you can't enter any of the groups. If you want to read any of the
news available on that server, you have to subscribe to the groups you
think may be interesting, and then you have to exit this buffer. The
new groups will be added to the group buffer, and then you can read them
as you would any other group.
Future versions of Gnus may possibly permit reading groups straight from the browse buffer.
Here's a list of keystrokes available in the browse mode:
gnus-group-next-group).
gnus-group-prev-group).
gnus-browse-read-group).
gnus-browse-select-group).
gnus-browse-unsubscribe-current-group).
gnus-browse-exit).
gnus-browse-describe-briefly).
Yes, Gnus is ex(c)iting.
gnus-group-suspend). This doesn't really exit Gnus,
but it kills all buffers except the Group buffer. I'm not sure why this
is a gain, but then who am I to judge?
gnus-group-exit).
gnus-group-quit).
gnus-suspend-gnus-hook is called when you suspend Gnus and
gnus-exit-gnus-hook is called when you quit Gnus.
If you wish to completely unload Gnus and all its adherents, you can use
the gnus-unload command. This command is also very handy when
trying to custoize meta-variables.
Note:
Miss Lisa Cannifax, while sitting in English class, feels her feet go numbly heavy and herself fall into a hazy trance as the boy sitting behind her drew repeated lines with his pencil across the back of her plastic chair.
gnus-group-get-new-news).
gnus-group-get-new-news-this-group).
gnus-group-enter-server-mode). See section The Server Buffer.
gnus-group-fetch-faq). Gnus will try to get the FAQ from
gnus-group-faq-directory, which is usually a directory on a
remote machine. ange-ftp will be used for fetching the file.
gnus-group-restart).
gnus-init-file, which defaults to
`~/.gnus') (gnus-group-read-init-file).
gnus-group-save-newsrc).
gnus-group-clear-dribble).
gnus-group-describe-group). If given
a prefix, force Gnus to re-read the description from the server.
gnus-group-apropos).
gnus-group-description-apropos).
gnus-group-post-news).
gnus-group-mail).
gnus-group-transpose-groups).
gnus-version).
gnus-group-describe-all-groups). If given a
prefix, force Gnus to re-read the description file from the server.
gnus-group-describe-briefly).
gnus-info-find-node).
gnus-group-prepare-hook is called after the group buffer is
generated. It may be used to modify the buffer in some strange,
unnatural way.