[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
If you are satisfied that you really never want to see any new groups,
you can 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 (see section Group Maintenance). This variable
is ask-server
by default. If you set this variable to
always
, then Gnus will query the back ends for new groups even
when you do the g command (see section Scanning New Messages).
1.4.1 Checking New Groups | Determining what groups are new. | |
1.4.2 Subscription Methods | What Gnus should do with new groups. | |
1.4.3 Filtering New Groups | Making Gnus ignore certain new groups. |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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 and cheaper. This also means that you can get rid of the list
of killed groups (see section Group Levels) 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
command.
I bet I know what you’re thinking now: How do I find out whether my
server supports ask-server
? No? Good, because I don’t have a
fail-safe answer. I would suggest just setting this variable to
ask-server
and see whether any new groups appear within the next
few days. If any do, then it works. If none do, then it doesn’t
work. I could write a function to make Gnus guess whether the server
supports ask-server
, but it would just be a guess. So I won’t.
You could telnet
to the server and say HELP
and see
whether it lists ‘NEWGROUPS’ among the commands it understands. If
it does, then it might work. (But there are servers that lists
‘NEWGROUPS’ without supporting the function properly.)
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 bliss.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
What Gnus does when it encounters a new group is determined by the
gnus-subscribe-newsgroup-method
variable.
This variable should contain a function. This function will be called with the name of the new group as the only parameter.
Some handy pre-fab functions are:
gnus-subscribe-zombies
Make all new groups zombies (see section Group Levels). This is the default. You can browse the zombies later (with A z) and either kill them all off properly (with S z), or subscribe to them (with u).
gnus-subscribe-randomly
Subscribe all new groups in arbitrary order. This really means that all new groups will be added at “the top” of the group buffer.
gnus-subscribe-alphabetically
Subscribe all new groups in alphabetical order.
gnus-subscribe-hierarchically
Subscribe all new groups hierarchically. The difference between this
function and gnus-subscribe-alphabetically
is slight.
gnus-subscribe-alphabetically
will subscribe new groups in a strictly
alphabetical fashion, while this function will enter groups into its
hierarchy. So if you want to have the ‘rec’ hierarchy before the
‘comp’ hierarchy, this function will not mess that configuration
up. Or something like that.
gnus-subscribe-interactively
Subscribe new groups interactively. This means that Gnus will ask you about all new groups. The groups you choose to subscribe to will be subscribed hierarchically.
gnus-subscribe-killed
Kill all new groups.
gnus-subscribe-topics
Put the groups into the topic that has a matching subscribe
topic
parameter (see section Topic Parameters). For instance, a subscribe
topic parameter that looks like
"nnml" |
will mean that all groups that match that regex will be subscribed under that topic.
If no topics match the groups, the groups will be subscribed in the top-level topic.
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 mistake is to set the variable a few paragraphs above
(gnus-subscribe-newsgroup-method
) to
gnus-subscribe-hierarchical-interactive
. This is an error. This
will not work. This is ga-ga. So don’t do it.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
A nice and portable 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
.
The “options -n” format is very simplistic. The syntax above is all that is supports: you can force-subscribe hierarchies, or you can deny hierarchies, and that’s it.
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 new group matches the former, it will be unconditionally
subscribed, and if it matches the latter, it will be ignored.
Yet another variable that meddles here is
gnus-auto-subscribed-groups
. It works exactly like
gnus-options-subscribe
, and is therefore really superfluous,
but I thought it would be nice to have two of these. This variable is
more meant for setting some ground rules, while the other variable is
used more for user fiddling. By default this variable makes all new
groups that come from mail back ends (nnml
, nnbabyl
,
nnfolder
, nnmbox
, nnmh
, nnimap
, and
nnmaildir
) subscribed. If you don’t like that, just set this
variable to nil
.
As if that wasn’t enough, gnus-auto-subscribed-categories
also
allows you to specify that new groups should be subscribed based on the
category their select methods belong to. The default is ‘(mail
post-mail)’, meaning that all new groups from mail-like backends
should be subscribed automatically.
New groups that match these variables are subscribed using
gnus-subscribe-options-newsgroup-method
.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] |
This document was generated on January 25, 2015 using texi2html 1.82.