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


Various

Process/Prefix

Many functions, among them functions for moving, decoding and saving articles, use what is known as the Process/Prefix convention.

This is a method for figuring out what articles that the user wants the command to be performed on.

It goes like this:

If the numeric prefix is N, perform the operation on the next N articles, starting with the current one. If the numeric prefix is negative, perform the operation on the previous N articles, starting with the current one.

If transient-mark-mode in non-nil and the region is active, all articles in the region will be worked upon.

If there is no numeric prefix, but some articles are marked with the process mark, perform the operation on the articles that are marked with the process mark.

If there is neither a numeric prefix nor any articles marked with the process mark, just perform the operation on the current article.

Quite simple, really, but it needs to be made clear so that surprises are avoided.

Commands that react to the process mark will push the current list of process marked articles onto a stack and will then clear all process marked articles. You can restore the previous configuration with the M P y command (see section Setting Process Marks).

One thing that seems to shock & horrify lots of people is that, for instance, 3 d does exactly the same as d d d. Since each d (which marks the current article as read) by default goes to the next unread article after marking, this means that 3 d will mark the next three unread articles as read, no matter what the summary buffer looks like. Set gnus-summary-goto-unread to nil for a more straightforward action.

Interactive

gnus-novice-user
If this variable is non-nil, you are either a newcomer to the World of Usenet, or you are very cautious, which is a nice thing to be, really. You will be given questions of the type "Are you sure you want to do this?" before doing anything dangerous. This is t by default.
gnus-expert-user
If this variable is non-nil, you will never ever be asked any questions by Gnus. It will simply assume you know what you're doing, no matter how strange.
gnus-interactive-catchup
Require confirmation before catching up a group if non-nil. It is t by default.
gnus-interactive-exit
Require confirmation before exiting Gnus. This variable is t by default.

Formatting Variables

Throughout this manual you've probably noticed lots of variables that are called things like gnus-group-line-format and gnus-summary-mode-line-format. These control how Gnus is to output lines in the various buffers. There's quite a lot of them. Fortunately, they all use the same syntax, so there's not that much to be annoyed by.

Here's an example format spec (from the group buffer): `%M%S%5y: %(%g%)\n'. We see that it is indeed extremely ugly, and that there are lots of percentages everywhere.

Currently Gnus uses the following formatting variables: gnus-group-line-format, gnus-summary-line-format, gnus-server-line-format, gnus-topic-line-format, gnus-group-mode-line-format, gnus-summary-mode-line-format, gnus-article-mode-line-format, gnus-server-mode-line-format, and gnus-summary-pick-line-format.

All these format variables can also be arbitrary elisp forms. In that case, they will be evaled to insert the required lines.

Gnus includes a command to help you while creating your own format specs. M-x gnus-update-format will eval the current form, update the spec in question and pop you to a buffer where you can examine the resulting lisp code to be run to generate the line.

Formatting Basics

Each `%' element will be replaced by some string or other when the buffer in question is generated. `%5y' means "insert the `y' spec, and pad with spaces to get a 5-character field".

As with normal C and Emacs Lisp formatting strings, the numerical modifier between the `%' and the formatting type character will pad the output so that it is always at least that long. `%5y' will make the field always (at least) five characters wide by padding with spaces to the left. If you say `%-5y', it will pad to the right instead.

You may also wish to limit the length of the field to protect against particularly wide values. For that you can say `%4,6y', which means that the field will never be more than 6 characters wide and never less than 4 characters wide.

Advanced Formatting

It is frequently useful to post-process the fields in some way. Padding, limiting, cutting off parts and suppressing certain values can be achieved by using tilde modifiers. A typical tilde spec might look like `%~(cut 3)~(ignore "0")y'.

These are the legal modifiers:

pad
pad-left
Pad the field to the left with spaces until it reaches the required length.
pad-right
Pad the field to the right with spaces until it reaches the required length.
max
max-left
Cut off characters from the left until it reaches the specified length.
max-right
Cut off characters from the right until it reaches the specified length.
cut
cut-left
Cut off the specified number of characters from the left.
cut-right
Cut off the specified number of characters from the right.
ignore
Return an empty string if the field is equal to the specified value.
form
Use the specified form as the field value when the `@' spec is used.

Let's take an example. The `%o' spec in the summary mode lines will return a date in compact ISO8601 format---`19960809T230410'. This is quite a mouthful, so we want to shave off the century number and the time, leaving us with a six-character date. That would be `%~(cut-left 2)~(max-right 6)~(pad 6)o'. (Cutting is done before maxing, and we need the padding to ensure that the date is never less than 6 characters to make it look nice in columns.)

Ignoring is done first; then cutting; then maxing; and then as the very last operation, padding.

If you use lots of these advanced thingies, you'll find that Gnus gets quite slow. This can be helped enormously by running M-x gnus-compile when you are satisfied with the look of your lines. See section Compilation.

User-Defined Specs

All the specs allow for inserting user defined specifiers---`u'. 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 a single parameter--what the parameter means depends on what buffer it's being called from. The function should return a string, which will be inserted into the buffer just like information from any other specifier. This function may also be called with dummy values, so it should protect against that.

You can also use tilde modifiers (see section Advanced Formatting to achieve much the same without defining new functions. Here's an example: `%~(form (count-lines (point-min) (point)))@'. The form given here will be evaluated to yield the current line number, and then inserted.

Formatting Fonts

There are specs for highlighting, and these are shared by all the format variables. Text inside the `%(' and `%)' specifiers will get the special mouse-face property set, which means that it will be highlighted (with gnus-mouse-face) when you put the mouse pointer over it.

Text inside the `%[' and `%]' specifiers will have their normal faces set using gnus-face-0, which is bold by default. If you say `%1[' instead, you'll get gnus-face-1 instead, and so on. Create as many faces as you wish. The same goes for the mouse-face specs--you can say `%3(hello%)' to have `hello' mouse-highlighted with gnus-mouse-face-3.

Here's an alternative recipe for the group buffer:

;; Create three face types.
(setq gnus-face-1 'bold)
(setq gnus-face-3 'italic)

;; We want the article count to be in 
;; a bold and green face.  So we create 
;; a new face called `my-green-bold'.
(copy-face 'bold 'my-green-bold)
;; Set the color.
(set-face-foreground 'my-green-bold "ForestGreen")
(setq gnus-face-2 'my-green-bold)

;; Set the new & fancy format.
(setq gnus-group-line-format 
      "%M%S%3{%5y%}%2[:%] %(%1{%g%}%)\n")

I'm sure you'll be able to use this scheme to create totally unreadable and extremely vulgar displays. Have fun!

Note that the `%(' specs (and friends) do not make any sense on the mode-line variables.

Windows Configuration

No, there's nothing here about X, so be quiet.

If gnus-use-full-window non-nil, Gnus will delete all other windows and occupy the entire Emacs screen by itself. It is t by default.

gnus-buffer-configuration describes how much space each Gnus buffer should be given. Here's an excerpt of this variable:

((group (vertical 1.0 (group 1.0 point)
                      (if gnus-carpal (group-carpal 4))))
 (article (vertical 1.0 (summary 0.25 point) 
                        (article 1.0))))

This is an alist. The key is a symbol that names some action or other. For instance, when displaying the group buffer, the window configuration function will use group as the key. A full list of possible names is listed below.

The value (i.e., the split) says how much space each buffer should occupy. To take the article split as an example -

(article (vertical 1.0 (summary 0.25 point)
                       (article 1.0)))

This split says that the summary buffer should occupy 25% of upper half of the screen, and that it is placed over the article buffer. As you may have noticed, 100% + 25% is actually 125% (yup, I saw y'all reaching for that calculator there). However, the special number 1.0 is used to signal that this buffer should soak up all the rest of the space available after the rest of the buffers have taken whatever they need. There should be only one buffer with the 1.0 size spec per split.

Point will be put in the buffer that has the optional third element point.

Here's a more complicated example:

(article (vertical 1.0 (group 4)
                       (summary 0.25 point)
                       (if gnus-carpal (summary-carpal 4))
                       (article 1.0)))

If the size spec is an integer instead of a floating point number, then that number will be used to say how many lines a buffer should occupy, not a percentage.

If the split looks like something that can be evaled (to be precise--if the car of the split is a function or a subr), this split will be evaled. If the result is non-nil, it will be used as a split. This means that there will be three buffers if gnus-carpal is nil, and four buffers if gnus-carpal is non-nil.

Not complicated enough for you? Well, try this on for size:

(article (horizontal 1.0 
             (vertical 0.5
                 (group 1.0)
                 (gnus-carpal 4))
             (vertical 1.0
                 (summary 0.25 point)
                 (summary-carpal 4)
                 (article 1.0))))

Whoops. Two buffers with the mystery 100% tag. And what's that horizontal thingie?

If the first element in one of the split is horizontal, Gnus will split the window horizontally, giving you two windows side-by-side. Inside each of these strips you may carry on all you like in the normal fashion. The number following horizontal says what percentage of the screen is to be given to this strip.

For each split, there must be one element that has the 100% tag. The splitting is never accurate, and this buffer will eat any leftover lines from the splits.

To be slightly more formal, here's a definition of what a legal split may look like:

split       = frame | horizontal | vertical | buffer | form
frame       = "(frame " size *split ")"
horizontal  = "(horizontal " size *split ")"
vertical    = "(vertical " size *split ")"
buffer      = "(" buffer-name " " size *[ "point" ] ")"
size        = number | frame-params
buffer-name = group | article | summary ...

The limitations are that the frame split can only appear as the top-level split. form should be an Emacs Lisp form that should return a valid split. We see that each split is fully recursive, and may contain any number of vertical and horizontal splits.

Finding the right sizes can be a bit complicated. No window may be less than gnus-window-min-height (default 1) characters high, and all windows must be at least gnus-window-min-width (default 1) characters wide. Gnus will try to enforce this before applying the splits. If you want to use the normal Emacs window width/height limit, you can just set these two variables to nil.

If you're not familiar with Emacs terminology, horizontal and vertical splits may work the opposite way of what you'd expect. Windows inside a horizontal split are shown side-by-side, and windows within a vertical split are shown above each other.

If you want to experiment with window placement, a good tip is to call gnus-configure-frame directly with a split. This is the function that does all the real work when splitting buffers. Below is a pretty nonsensical configuration with 5 windows; two for the group buffer and three for the article buffer. (I said it was nonsensical.) If you eval the statement below, you can get an idea of how that would look straight away, without going through the normal Gnus channels. Play with it until you're satisfied, and then use gnus-add-configuration to add your new creation to the buffer configuration list.

(gnus-configure-frame
 '(horizontal 1.0
    (vertical 10
      (group 1.0)
      (article 0.3 point))
    (vertical 1.0
      (article 1.0)
      (horizontal 4
        (group 1.0)
        (article 10)))))

You might want to have several frames as well. No prob--just use the frame split:

(gnus-configure-frame
 '(frame 1.0
         (vertical 1.0
                   (summary 0.25 point)
                   (article 1.0))
         (vertical ((height . 5) (width . 15)
                    (user-position . t)
                    (left . -1) (top . 1))
                   (picon 1.0))))

This split will result in the familiar summary/article window configuration in the first (or "main") frame, while a small additional frame will be created where picons will be shown. As you can see, instead of the normal 1.0 top-level spec, each additional split should have a frame parameter alist as the size spec. See section `Frame Parameters' in The GNU Emacs Lisp Reference Manual.

Here's a list of all possible keys for gnus-buffer-configuration:

group, summary, article, server, browse, message, pick, info, summary-faq, edit-group, edit-server, edit-score, post, reply, forward, reply-yank, mail-bounce, draft, pipe, bug, compose-bounce.

Note that the message key is used for both gnus-group-mail and gnus-summary-mail-other-window. If it is desirable to distinguish between the two, something like this might be used:

(message (horizontal 1.0
                     (vertical 1.0 (message 1.0 point))
                     (vertical 0.24
                               (if (buffer-live-p gnus-summary-buffer)
                                   '(summary 0.5))
                               (group 1.0)))))

Since the gnus-buffer-configuration variable is so long and complicated, there's a function you can use to ease changing the config of a single setting: gnus-add-configuration. If, for instance, you want to change the article setting, you could say:

(gnus-add-configuration
 '(article (vertical 1.0
               (group 4)
               (summary .25 point)
               (article 1.0))))

You'd typically stick these gnus-add-configuration calls in your `.gnus.el' file or in some startup hook--they should be run after Gnus has been loaded.

If all windows mentioned in the configuration are already visible, Gnus won't change the window configuration. If you always want to force the "right" window configuration, you can set gnus-always-force-window-configuration to non-nil.

Compilation

Remember all those line format specification variables? gnus-summary-line-format, gnus-group-line-format, and so on. Now, Gnus will of course heed whatever these variables are, but, unfortunately, changing them will mean a quite significant slow-down. (The default values of these variables have byte-compiled functions associated with them, while the user-generated versions do not, of course.)

To help with this, you can run M-x gnus-compile after you've fiddled around with the variables and feel that you're (kind of) satisfied. This will result in the new specs being byte-compiled, and you'll get top speed again. Gnus will save these compiled specs in the `.newsrc.eld' file. (User-defined functions aren't compiled by this function, though--you should compile them yourself by sticking them into the .gnus.el file and byte-compiling that file.)

Mode Lines

gnus-updated-mode-lines says what buffers should keep their mode lines updated. It is a list of symbols. Supported symbols include group, article, summary, server, browse, and tree. If the corresponding symbol is present, Gnus will keep that mode line updated with information that may be pertinent. If this variable is nil, screen refresh may be quicker.

By default, Gnus displays information on the current article in the mode lines of the summary and article buffers. The information Gnus wishes to display (e.g. the subject of the article) is often longer than the mode lines, and therefore have to be cut off at some point. The gnus-mode-non-string-length variable says how long the other elements on the line is (i.e., the non-info part). If you put additional elements on the mode line (e.g. a clock), you should modify this variable:

(add-hook 'display-time-hook
          (lambda () (setq gnus-mode-non-string-length
                           (+ 21
                              (if line-number-mode 5 0)
                              (if column-number-mode 4 0)
                              (length display-time-string)))))

If this variable is nil (which is the default), the mode line strings won't be chopped off, and they won't be padded either. Note that the default is unlikely to be desirable, as even the percentage complete in the buffer may be crowded off the mode line; the user should configure this variable appropriately for their configuration.

Highlighting and Menus

The gnus-visual variable controls most of the prettifying Gnus aspects. If nil, Gnus won't attempt to create menus or use fancy colors or fonts. This will also inhibit loading the `gnus-vis.el' file.

This variable can be a list of visual properties that are enabled. The following elements are legal, and are all included by default:

group-highlight
Do highlights in the group buffer.
summary-highlight
Do highlights in the summary buffer.
article-highlight
Do highlights in the article buffer.
highlight
Turn on highlighting in all buffers.
group-menu
Create menus in the group buffer.
summary-menu
Create menus in the summary buffers.
article-menu
Create menus in the article buffer.
browse-menu
Create menus in the browse buffer.
server-menu
Create menus in the server buffer.
score-menu
Create menus in the score buffers.
menu
Create menus in all buffers.

So if you only want highlighting in the article buffer and menus in all buffers, you could say something like:

(setq gnus-visual '(article-highlight menu))

If you want only highlighting and no menus whatsoever, you'd say:

(setq gnus-visual '(highlight))

If gnus-visual is t, highlighting and menus will be used in all Gnus buffers.

Other general variables that influence the look of all buffers include:

gnus-mouse-face
This is the face (i.e., font) used for mouse highlighting in Gnus. No mouse highlights will be done if gnus-visual is nil.

There are hooks associated with the creation of all the different menus:

gnus-article-menu-hook
Hook called after creating the article mode menu.
gnus-group-menu-hook
Hook called after creating the group mode menu.
gnus-summary-menu-hook
Hook called after creating the summary mode menu.
gnus-server-menu-hook
Hook called after creating the server mode menu.
gnus-browse-menu-hook
Hook called after creating the browse mode menu.
gnus-score-menu-hook
Hook called after creating the score mode menu.

Buttons

Those new-fangled mouse contraptions is very popular with the young, hep kids who don't want to learn the proper way to do things these days. Why, I remember way back in the summer of '89, when I was using Emacs on a Tops 20 system. Three hundred users on one single machine, and every user was running Simula compilers. Bah!

Right.

Well, you can make Gnus display bufferfuls of buttons you can click to do anything by setting gnus-carpal to t. Pretty simple, really. Tell the chiropractor I sent you.

gnus-carpal-mode-hook
Hook run in all carpal mode buffers.
gnus-carpal-button-face
Face used on buttons.
gnus-carpal-header-face
Face used on carpal buffer headers.
gnus-carpal-group-buffer-buttons
Buttons in the group buffer.
gnus-carpal-summary-buffer-buttons
Buttons in the summary buffer.
gnus-carpal-server-buffer-buttons
Buttons in the server buffer.
gnus-carpal-browse-buffer-buttons
Buttons in the browse buffer.

All the buttons variables are lists. The elements in these list is either a cons cell where the car contains a text to be displayed and the cdr contains a function symbol, or a simple string.

Daemons

Gnus, being larger than any program ever written (allegedly), does lots of strange stuff that you may wish to have done while you're not present. For instance, you may want it to check for new mail once in a while. Or you may want it to close down all connections to all servers when you leave Emacs idle. And stuff like that.

Gnus will let you do stuff like that by defining various handlers. Each handler consists of three elements: A function, a time, and an idle parameter.

Here's an example of a handler that closes connections when Emacs has been idle for thirty minutes:

(gnus-demon-close-connections nil 30)

Here's a handler that scans for PGP headers every hour when Emacs is idle:

(gnus-demon-scan-pgp 60 t)

This time parameter and than idle parameter works together in a strange, but wonderful fashion. Basically, if idle is nil, then the function will be called every time minutes.

If idle is t, then the function will be called after time minutes only if Emacs is idle. So if Emacs is never idle, the function will never be called. But once Emacs goes idle, the function will be called every time minutes.

If idle is a number and time is a number, the function will be called every time minutes only when Emacs has been idle for idle minutes.

If idle is a number and time is nil, the function will be called once every time Emacs has been idle for idle minutes.

And if time is a string, it should look like `07:31', and the function will then be called once every day somewhere near that time. Modified by the idle parameter, of course.

(When I say "minute" here, I really mean gnus-demon-timestep seconds. This is 60 by default. If you change that variable, all the timings in the handlers will be affected.)

To set the whole thing in motion, though, you have to set gnus-use-demon to t.

So, if you want to add a handler, you could put something like this in your `.gnus' file:

(gnus-demon-add-handler 'gnus-demon-close-connections nil 30)

Some ready-made functions to do this has been created: gnus-demon-add-nocem, gnus-demon-add-disconnection, gnus-demon-add-rescan, and gnus-demon-add-scanmail. Just put those functions in your `.gnus' if you want those abilities.

If you add handlers to gnus-demon-handlers directly, you should run gnus-demon-init to make the changes take hold. To cancel all daemons, you can use the gnus-demon-cancel function.

Note that adding daemons can be pretty naughty if you overdo it. Adding functions that scan all news and mail from all servers every two seconds is a sure-fire way of getting booted off any respectable system. So behave.

NoCeM

Spamming is posting the same article lots and lots of times. Spamming is bad. Spamming is evil.

Spamming is usually canceled within a day or so by various anti-spamming agencies. These agencies usually also send out NoCeM messages. NoCeM is pronounced "no see-'em", and means what the name implies--these are messages that make the offending articles, like, go away.

What use are these NoCeM messages if the articles are canceled anyway? Some sites do not honor cancel messages and some sites just honor cancels from a select few people. Then you may wish to make use of the NoCeM messages, which are distributed in the `alt.nocem.misc' newsgroup.

Gnus can read and parse the messages in this group automatically, and this will make spam disappear.

There are some variables to customize, of course:

gnus-use-nocem
Set this variable to t to set the ball rolling. It is nil by default.
gnus-nocem-groups
Gnus will look for NoCeM messages in the groups in this list. The default is ("news.lists.filters" "news.admin.net-abuse.bulletins" "alt.nocem.misc" "news.admin.net-abuse.announce").
gnus-nocem-issuers
There are many people issuing NoCeM messages. This list says what people you want to listen to. The default is ("Automoose-1" "clewis@ferret.ocunix.on.ca;" "jem@xpat.com;" "red@redpoll.mrfs.oh.us (Richard E. Depew)"); fine, upstanding citizens all of them. Known despammers that you can put in this list include:
`clewis@ferret.ocunix.on.ca;'
Chris Lewis--Major Canadian despammer who has probably canceled more usenet abuse than anybody else.
`Automoose-1'
The CancelMoose[tm] on autopilot. The CancelMoose[tm] is reputed to be Norwegian, and was the person(s) who invented NoCeM.
`jem@xpat.com;'
John Milburn--despammer located in Korea who is getting very busy these days.
`red@redpoll.mrfs.oh.us (Richard E. Depew)'
Richard E. Depew--lone American despammer. He mostly cancels binary postings to non-binary groups and removes spews (regurgitated articles).
You do not have to heed NoCeM messages from all these people--just the ones you want to listen to.
gnus-nocem-verifyer
This should be a function for verifying that the NoCeM issuer is who she says she is. The default is mc-verify, which is a Mailcrypt function. If this is too slow and you don't care for verification (which may be dangerous), you can set this variable to nil. If you want signed NoCeM messages to be verified and unsigned messages not to be verified (but used anyway), you could do something like:
(setq gnus-nocem-verifyer 'my-gnus-mc-verify)

(defun my-gnus-mc-verify ()
  (not (eq 'forged
           (ignore-errors
             (if (mc-verify)
                 t
               'forged)))))
This might be dangerous, though.
gnus-nocem-directory
This is where Gnus will store its NoCeM cache files. The default is `~/News/NoCeM/'.
gnus-nocem-expiry-wait
The number of days before removing old NoCeM entries from the cache. The default is 15. If you make it shorter Gnus will be faster, but you might then see old spam.

Picons

So... You want to slow down your news reader even more! This is a good way to do so. Its also a great way to impress people staring over your shoulder as you read news.

Picon Basics

What are Picons? To quote directly from the Picons Web site:

Picons is short for "personal icons". They're small, constrained images used to represent users and domains on the net, organized into databases so that the appropriate image for a given e-mail address can be found. Besides users and domains, there are picon databases for Usenet newsgroups and weather forecasts. The picons are in either monochrome XBM format or color XPM and GIF formats.

For instructions on obtaining and installing the picons databases, point your Web browser at `http://www.cs.indiana.edu/picons/ftp/index.html'.

Gnus expects picons to be installed into a location pointed to by gnus-picons-database.

Picon Requirements

To use have Gnus display Picons for you, you must be running XEmacs 19.13 or greater since all other versions of Emacs aren't yet able to display images.

Additionally, you must have xpm support compiled into XEmacs.

If you want to display faces from X-Face headers, you must have the netpbm utilities installed, or munge the gnus-picons-convert-x-face variable to use something else.

Easy Picons

To enable displaying picons, simply put the following line in your `~/.gnus' file and start Gnus.

(setq gnus-use-picons t)
(add-hook 'gnus-article-display-hook 'gnus-article-display-picons t)
(add-hook 'gnus-summary-prepare-hook 'gnus-group-display-picons t)
(add-hook 'gnus-article-display-hook 'gnus-picons-article-display-x-face)

Hard Picons

Gnus can display picons for you as you enter and leave groups and articles. It knows how to interact with three sections of the picons database. Namely, it can display the picons newsgroup pictures, author's face picture(s), and the authors domain. To enable this feature, you need to first decide where to display them.

gnus-picons-display-where
Where the picon images should be displayed. It is picons by default (which by default maps to the buffer `*Picons*'). Other valid places could be article, summary, or `*scratch*' for all I care. Just make sure that you've made the buffer visible using the standard Gnus window configuration routines---see section Windows Configuration.

Note: If you set gnus-use-picons to t, it will set up your window configuration for you to include the picons buffer.

Now that you've made that decision, you need to add the following functions to the appropriate hooks so these pictures will get displayed at the right time.

gnus-article-display-picons
Looks up and display the picons for the author and the author's domain in the gnus-picons-display-where buffer. Should be added to the gnus-article-display-hook.
gnus-group-display-picons
Displays picons representing the current group. This function should be added to the gnus-summary-prepare-hook or to the gnus-article-display-hook if gnus-picons-display-where is set to article.
gnus-picons-article-display-x-face
Decodes and displays the X-Face header if present. This function should be added to gnus-article-display-hook.

Note: You must append them to the hook, so make sure to specify 't' to the append flag of add-hook:

(add-hook 'gnus-article-display-hook 'gnus-article-display-picons t)

Picon Configuration

The following variables offer further control over how things are done, where things are located, and other useless stuff you really don't need to worry about.

gnus-picons-database
The location of the picons database. Should point to a directory containing the `news', `domains', `users' (and so on) subdirectories. Defaults to `/usr/local/faces'.
gnus-picons-news-directory
Sub-directory of the faces database containing the icons for newsgroups.
gnus-picons-user-directories
List of subdirectories to search in gnus-picons-database for user faces. ("local" "users" "usenix" "misc/MISC") is the default.
gnus-picons-domain-directories
List of subdirectories to search in gnus-picons-database for domain name faces. Defaults to ("domains"). Some people may want to add `unknown' to this list.
gnus-picons-convert-x-face
The command to use to convert the X-Face header to an X bitmap (xbm). Defaults to (format "{ echo '/* Width=48, Height=48 */'; uncompface; } | icontopbm | pbmtoxbm > %s" gnus-picons-x-face-file-name)
gnus-picons-x-face-file-name
Names a temporary file to store the X-Face bitmap in. Defaults to (format "/tmp/picon-xface.%s.xbm" (user-login-name)).
gnus-picons-buffer
The name of the buffer that picons points to. Defaults to `*Icon Buffer*'.

Undo

It is very useful to be able to undo actions one has done. In normal Emacs buffers, it's easy enough--you just push the undo button. In Gnus buffers, however, it isn't that simple.

The things Gnus displays in its buffer is of no value whatsoever to Gnus--it's all just data that is designed to look nice to the user. Killing a group in the group buffer with C-k makes the line disappear, but that's just a side-effect of the real action--the removal of the group in question from the internal Gnus structures. Undoing something like that can't be done by the normal Emacs undo function.

Gnus tries to remedy this somewhat by keeping track of what the user does and coming up with actions that would reverse the actions the user takes. When the user then presses the undo key, Gnus will run the code to reverse the previous action, or the previous actions. However, not all actions are easily reversible, so Gnus currently offers a few key functions to be undoable. These include killing groups, yanking groups, and changing the list of read articles of groups. That's it, really. More functions may be added in the future, but each added function means an increase in data to be stored, so Gnus will never be totally undoable.

The undoability is provided by the gnus-undo-mode minor mode. It is used if gnus-use-undo is non-nil, which is the default. The M-C-_ key performs the gnus-undo command command, which should feel kinda like the normal Emacs undo command.

Moderation

If you are a moderator, you can use the `gnus-mdrtn.el' package. It is not included in the standard Gnus package. Write a mail to `larsi@gnus.org' and state what group you moderate, and you'll get a copy.

The moderation package is implemented as a minor mode for summary buffers. Put

(add-hook 'gnus-summary-mode-hook 'gnus-moderate)

in your `.gnus.el' file.

If you are the moderation of `rec.zoofle', this is how it's supposed to work:

  1. You split your incoming mail by matching on `Newsgroups:.*rec.zoofle', which will put all the to-be-posted articles in some mail group--for instance, `nnml:rec.zoofle'.
  2. You enter that group once in a while and post articles using the e (edit-and-post) or s (just send unedited) commands.
  3. If, while reading the `rec.zoofle' newsgroup, you happen upon some articles that weren't approved by you, you can cancel them with the c command.

To use moderation mode in these two groups, say:

(setq gnus-moderated-list
      "^nnml:rec.zoofle$\\|^rec.zoofle$")

XEmacs Enhancements

XEmacs is able to display pictures and stuff, so Gnus has taken advantage of that. Relevant variables include:

gnus-xmas-glyph-directory
This is where Gnus will look for pictures. Gnus will normally auto-detect this directory, but you may set it manually if you have an unusual directory structure.
gnus-xmas-logo-color-alist
This is an alist where the key is a type symbol and the values are the foreground and background color of the splash page glyph.
gnus-xmas-logo-color-style
This is the key used to look up the color in the alist described above. Legal values include flame, pine, moss, irish, sky, tin, velvet, grape, labia, berry, neutral, and september.
gnus-use-toolbar
If nil, don't display toolbars. If non-nil, it should be one of default-toolbar, top-toolbar, bottom-toolbar, right-toolbar, or left-toolbar.
gnus-group-toolbar
The toolbar in the group buffer.
gnus-summary-toolbar
The toolbar in the summary buffer.
gnus-summary-mail-toolbar
The toolbar in the summary buffer of mail groups.
gnus-xmas-modeline-glyph
A glyph displayed in all Gnus mode lines. It is a tiny gnu head by default.

Fuzzy Matching

Gnus provides fuzzy matching of Subject lines when doing things like scoring, thread gathering and thread comparison.

As opposed to regular expression matching, fuzzy matching is very fuzzy. It's so fuzzy that there's not even a definition of what fuzziness means, and the implementation has changed over time.

Basically, it tries to remove all noise from lines before comparing. `Re: ', parenthetical remarks, white space, and so on, are filtered out of the strings before comparing the results. This often leads to adequate results--even when faced with strings generated by text manglers masquerading as newsreaders.

Thwarting Email Spam

In these last days of the Usenet, commercial vultures are hanging about and grepping through news like crazy to find email addresses they can foist off their scams and products to. As a reaction to this, many people have started putting nonsense addresses into their From lines. I think this is counterproductive--it makes it difficult for people to send you legitimate mail in response to things you write, as well as making it difficult to see who wrote what. This rewriting may perhaps be a bigger menace than the unsolicited commercial email itself in the end.

The biggest problem I have with email spam is that it comes in under false pretenses. I press g and Gnus merrily informs me that I have 10 new emails. I say "Golly gee! Happy is me!" and selects the mail group, only to find two pyramid schemes, seven advertisements ("New! Miracle tonic for growing full, lustrouos hair on your toes!") and one mail asking me to repent and find some god.

This is annoying.

The way to deal with this is having Gnus split out all spam into a `spam' mail group (see section Splitting Mail).

First, pick one (1) legal mail address that you can be reached at, and put it in your From header of all your news articles. (I've chosen `larsi@trym.ifi.uio.no'.)

(setq message-default-news-headers
      "From: Lars Magne Ingebrigtsen <larsi@trym.ifi.uio.no>\n")

Then put the following split rule in nnmail-split-fancy (see section Fancy Mail Splitting):

(
 ...
 (to "larsi@trym.ifi.uio.no"
      (| ("subject" "re:.*" "misc")
         ("references" ".*@.*" "misc")
         "spam"))
 ...
)

This says that all mail to this address is suspect, but if it has a Subject that starts with a `Re:' or has a References header, it's probably ok. All the rest goes to the `spam' group. (This idea probably comes from Tim Pierce.)

In addition, many mail spammers talk directly to your smtp server and do not include your email address explicitly in the To header. Why they do this is unknown--perhaps it's to thwart this twarting scheme? In any case, this is trivial to deal with--you just put anything not addressed to you in the `spam' group by ending your fancy split rule in this way:

(
 ...
 (to "larsi" "misc")
 "spam")

In my experience, this will sort virtually everything into the right group. You still have to check the `spam' group from time to time to check for legitimate mail, though. If you feel like being a good net citizen, you can even send off complaints to the proper authorities on each unsolicited commercial email--at your leisure.

This works for me. It allows people an easy way to contact me (they can just press r in the usual way), and I'm not bothered at all with spam. It's a win-win situation. Forging From headers to point to non-existant domains is yucky, in my opinion.

Various Various

gnus-home-directory
All Gnus path variables will be initialized from this variable, which defaults to `~/'.
gnus-directory
Most Gnus storage path variables will be initialized from this variable, which defaults to the `SAVEDIR' environment variable, or `~/News/' if that variable isn't set.
gnus-default-directory
Not related to the above variable at all--this variable says what the default directory of all Gnus buffers should be. If you issue commands like C-x C-f, the prompt you'll get starts in the current buffer's default directory. If this variable is nil (which is the default), the default directory will be the default directory of the buffer you were in when you started Gnus.
gnus-verbose
This variable is an integer between zero and ten. The higher the value, the more messages will be displayed. If this variable is zero, Gnus will never flash any messages, if it is seven (which is the default), most important messages will be shown, and if it is ten, Gnus won't ever shut up, but will flash so many messages it will make your head swim.
gnus-verbose-backends
This variable works the same way as gnus-verbose, but it applies to the Gnus backends instead of Gnus proper.
nnheader-max-head-length
When the backends read straight heads of articles, they all try to read as little as possible. This variable (default 4096) specifies the absolute max length the backends will try to read before giving up on finding a separator line between the head and the body. If this variable is nil, there is no upper read bound. If it is t, the backends won't try to read the articles piece by piece, but read the entire articles. This makes sense with some versions of ange-ftp.
nnheader-head-chop-length
This variable says how big a piece of each article to read when doing the operation described above.
nnheader-file-name-translation-alist
This is an alist that says how to translate characters in file names. For instance, if `:' is illegal as a file character in file names on your system (you OS/2 user you), you could say something like:
(setq nnheader-file-name-translation-alist 
      '((?: . ?_)))
In fact, this is the default value for this variable on OS/2 and MS Windows (phooey) systems.
gnus-hidden-properties
This is a list of properties to use to hide "invisible" text. It is (invisible t intangible t) by default on most systems, which makes invisible text invisible and intangible.
gnus-parse-headers-hook
A hook called before parsing headers. It can be used, for instance, to gather statistics on the headers fetched, or perhaps you'd like to prune some headers. I don't see why you'd want that, though.
gnus-shell-command-separator
String used to separate to shell commands. The default is `;'.


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