This is ../info/gnus, produced by makeinfo version 4.0 from gnus.texi.
INFO-DIR-SECTION Emacs
START-INFO-DIR-ENTRY
* Gnus: (gnus). The newsreader Gnus.
END-INFO-DIR-ENTRY
This file documents Gnus, the GNU Emacs newsreader.
Copyright (C) 1995,96,97,98,99,2000,2001 Free Software Foundation,
Inc.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.1 or
any later version published by the Free Software Foundation; with the
Invariant Sections being none, with the Front-Cover texts being "A GNU
Manual", and with the Back-Cover Texts as in (a) below. A copy of the
license is included in the section entitled "GNU Free Documentation
License" in the Emacs manual.
(a) The FSF's Back-Cover Text is: "You have freedom to copy and
modify this GNU Manual, like GNU software. Copies published by the Free
Software Foundation raise funds for GNU development."
This document is part of a collection distributed under the GNU Free
Documentation License. If you want to distribute this document
separately from the collection, you can do so by adding a copy of the
license to the document, as described in section 6 of the license.
File: gnus, Node: Windows Configuration, Next: Faces and Fonts, Prev: Formatting Variables, Up: Various
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.
Setting this variable to `nil' kinda works, but there are glitches.
Use at your own peril.
`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'. In a `frame' split, the last subsplit having a leaf split
where the tag `frame-focus' is a member (i.e. is the third or fourth
element in the list, depending on whether the `point' tag is present)
gets focus.
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 `eval'ed (to be
precise--if the `car' of the split is a function or a subr), this split
will be `eval'ed. 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 valid split
may look like:
split = frame | horizontal | vertical | buffer | form
frame = "(frame " size *split ")"
horizontal = "(horizontal " size *split ")"
vertical = "(vertical " size *split ")"
buffer = "(" buf-name " " size *[ "point" ] *[ "frame-focus"] ")"
size = number | frame-params
buf-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 frame-focus)
(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. *Note Frame
Parameters: (elisp)Frame Parameters. Under XEmacs, a frame property
list will be accepted, too--for instance, `(height 5 width 15 left -1
top 1)' is such a plist. The list of all possible keys for
`gnus-buffer-configuration' can be found in its default value.
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)))))
One common desire for a multiple frame split is to have a separate
frame for composing mail and news while leaving the original frame
intact. To accomplish that, something like the following can be done:
(message
(frame 1.0
(if (not (buffer-live-p gnus-summary-buffer))
(car (cdr (assoc 'group gnus-buffer-configuration)))
(car (cdr (assoc 'summary gnus-buffer-configuration))))
(vertical ((user-position . t) (top . 1) (left . 1)
(name . "Message"))
(message 1.0 point))))
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'.
If you're using tree displays (*note Tree Display::), and the tree
window is displayed vertically next to another window, you may also want
to fiddle with `gnus-tree-minimize-window' to avoid having the windows
resized.
Example Window Configurations
-----------------------------
* Narrow left hand side occupied by group buffer. Right hand side
split between summary buffer (top one-sixth) and article buffer
(bottom).
+---+---------+
| G | Summary |
| r +---------+
| o | |
| u | Article |
| p | |
+---+---------+
(gnus-add-configuration
'(article
(horizontal 1.0
(vertical 25 (group 1.0))
(vertical 1.0
(summary 0.16 point)
(article 1.0)))))
(gnus-add-configuration
'(summary
(horizontal 1.0
(vertical 25 (group 1.0))
(vertical 1.0 (summary 1.0 point)))))
File: gnus, Node: Faces and Fonts, Next: Compilation, Prev: Windows Configuration, Up: Various
Faces and Fonts
===============
Fiddling with fonts and faces used to be very difficult, but these
days it is very simple. You simply say `M-x customize-face', pick out
the face you want to alter, and alter it via the standard Customize
interface.
File: gnus, Node: Compilation, Next: Mode Lines, Prev: Faces and Fonts, Up: Various
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.)
File: gnus, Node: Mode Lines, Next: Highlighting and Menus, Prev: Compilation, Up: Various
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 her configuration.
File: gnus, Node: Highlighting and Menus, Next: Buttons, Prev: Mode Lines, Up: Various
Highlighting and Menus
======================
The `gnus-visual' variable controls most of the Gnus-prettifying
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 valid, 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 highlighting only 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.
File: gnus, Node: Buttons, Next: Daemons, Prev: Highlighting and Menus, Up: Various
Buttons
=======
Those new-fangled "mouse" contraptions are 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 buffers full 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
are either cons cells where the `car' contains a text to be displayed
and the `cdr' contains a function symbol, or a simple string.
File: gnus, Node: Daemons, Next: NoCeM, Prev: Buttons, Up: Various
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 work 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.)
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 30 t)
Some ready-made functions to do this have been created:
`gnus-demon-add-nocem', `gnus-demon-add-disconnection',
`gnus-demon-add-nntp-close-connection',
`gnus-demon-add-scan-timestamps', `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 over do 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.
File: gnus, Node: NoCeM, Next: Undo, Prev: Daemons, Up: Various
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" "cosmo.roadkill" "SpamHippo"
"hweede@snafu.de")'; fine, upstanding citizens all of them.
Known despammers that you can put in this list are listed at
`http://www.xs4all.nl/~rosalind/nocemreg/nocemreg.html'.
You do not have to heed NoCeM messages from all these people--just
the ones you want to listen to. You also don't have to accept all
NoCeM messages from the people you like. Each NoCeM message has a
"type" header that gives the message a (more or less, usually
less) rigorous definition. Common types are `spam', `spew', `mmf',
`binary', and `troll'. To specify this, you have to use `(ISSUER
CONDITIONS ...)' elements in the list. Each condition is either a
string (which is a regexp that matches types you want to use) or a
list on the form `(not STRING)', where STRING is a regexp that
matches types you don't want to use.
For instance, if you want all NoCeM messages from Chris Lewis
except his `troll' messages, you'd say:
("clewis@ferret.ocunix.on.ca" ".*" (not "troll"))
On the other hand, if you just want nothing but his `spam' and
`spew' messages, you'd say:
("clewis@ferret.ocunix.on.ca" (not ".*") "spew" "spam")
The specs are applied left-to-right.
`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.
`gnus-nocem-check-from'
Non-`nil' means check for valid issuers in message bodies.
Otherwise don't bother fetching articles unless their author
matches a valid issuer; that is much faster if you are selective
about the issuers.
`gnus-nocem-check-article-limit'
If non-`nil', the maximum number of articles to check in any NoCeM
group. NoCeM groups can be huge and very slow to process.
Using NoCeM could potentially be a memory hog. If you have many
living (i. e., subscribed or unsubscribed groups), your Emacs process
will grow big. If this is a problem, you should kill off all (or most)
of your unsubscribed groups (*note Subscription Commands::).
File: gnus, Node: Undo, Next: Moderation, Prev: NoCeM, Up: Various
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 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, which should feel kinda
like the normal Emacs `undo' command.
File: gnus, Node: Moderation, Next: Emacs Enhancements, Prev: Undo, Up: Various
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 moderator 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$")
File: gnus, Node: Emacs Enhancements, Next: XEmacs Enhancements, Prev: Moderation, Up: Various
Emacs Enhancements
==================
Starting with version 21, Emacs is able to display pictures and
stuff, so Gnus has taken advantage of that.
Gnus-specific tool bars will be used if Tool Bar mode is on.
Currently the group, summary and message buffers have tool bars defined.
MIME image types may be displayed internally if Emacs was built with
appropriate support (see variable `image-types'). `X-Face' headers may
be rendered as images internally if you have appropriate support
programs (*note X-Face::). You can play sounds internally if Emacs was
built with suitable audio support; otherwise Gnus will attempt to play
sounds externally.
A simplified version of the XEmacs Smiley support for "emoticons"
(*note Smileys::) is available on graphical displays under the control
of `gnus-treat-display-smileys'. Text `smiley' faces--`:-)', `:-/',
`:-(' and the like--are mapped to pictures which are displayed instead.
The mapping is controlled by a list of regexps `smiley-regexp-alist'
mapping matched text to image file names. It contains matches for
`smiley', `wry' and `frowny' by default.
There is currently no Emacs support for `Picons' (*note Picons::),
but there is no reason why it couldn't be added.
File: gnus, Node: XEmacs Enhancements, Next: Fuzzy Matching, Prev: Emacs Enhancements, Up: Various
XEmacs Enhancements
===================
XEmacs is able to display pictures and stuff, so Gnus has taken
advantage of that.
* Menu:
* Picons:: How to display pictures of what your reading.
* Smileys:: Show all those happy faces the way they were meant to be shown.
* Toolbar:: Click'n'drool.
* XVarious:: Other XEmacsy Gnusey variables.
File: gnus, Node: Picons, Next: Smileys, Up: XEmacs Enhancements
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.
* Menu:
* Picon Basics:: What are picons and How do I get them.
* Picon Requirements:: Don't go further if you aren't using XEmacs.
* Easy Picons:: Displaying Picons---the easy way.
* Hard Picons:: The way you should do it. You'll learn something.
* Picon Useless Configuration:: Other variables you can trash/tweak/munge/play with.
File: gnus, Node: Picon Basics, Next: Picon Requirements, Up: Picons
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.
If you have a permanent connection to the Internet you can use Steve
Kinzler's Picons Search engine by setting `gnus-picons-piconsearch-url'
to the string
`http://www.cs.indiana.edu/picons/search.html'.
Otherwise you need a local copy of his database. 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'.
File: gnus, Node: Picon Requirements, Next: Easy Picons, Prev: Picon Basics, Up: Picons
Picon Requirements
..................
To 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 `x' support compiled into XEmacs. To
display color picons which are much nicer than the black & white one,
you also need one of `xpm' or `gif' compiled into XEmacs.
If you want to display faces from `X-Face' headers, you should have
the `xface' support compiled into XEmacs. Otherwise you must have the
`netpbm' utilities installed, or munge the `gnus-picons-convert-x-face'
variable to use something else.
File: gnus, Node: Easy Picons, Next: Hard Picons, Prev: Picon Requirements, Up: Picons
Easy Picons
...........
To enable displaying picons, simply put the following line in your
`~/.gnus' file and start Gnus.
(setq gnus-use-picons t)
(setq gnus-treat-display-picons t)
and make sure `gnus-picons-database' points to the directory
containing the Picons databases.
Alternatively if you want to use the web piconsearch engine add this:
(setq gnus-picons-piconsearch-url
"http://www.cs.indiana.edu:800/piconsearch")
File: gnus, Node: Hard Picons, Next: Picon Useless Configuration, Prev: Easy Picons, Up: Picons
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 select where to get the picons from, and where to
display them.
`gnus-picons-database'
The location of the picons database. Should point to a directory
containing the `news', `domains', `users' (and so on)
subdirectories. This is only useful if
`gnus-picons-piconsearch-url' is `nil'. Defaults to
`/usr/local/faces/'.
`gnus-picons-piconsearch-url'
The URL for the web picons search engine. The only currently known
engine is `http://www.cs.indiana.edu:800/piconsearch'. To
workaround network delays, icons will be fetched in the
background. If this is `nil' 'the default), then picons are
fetched from local database indicated by `gnus-picons-database'.
`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--*note Windows
Configuration::.
`gnus-picons-group-excluded-groups'
Groups that are matched by this regexp won't have their group icons
displayed.
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 those 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 displays the picons for the author and the author's
domain in the `gnus-picons-display-where' buffer.
`gnus-picons-article-display-x-face'
Decodes and displays the X-Face header if present.
File: gnus, Node: Picon Useless Configuration, Prev: Hard Picons, Up: Picons
Picon Useless 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-news-directories'
List of subdirectories to search in `gnus-picons-database' for
newsgroups faces. `("news")' is the default.
`gnus-picons-user-directories'
List of subdirectories to search in `gnus-picons-database' for user
faces. `("local" "users" "usenix" "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'
If you don't have `xface' support builtin XEmacs, this is 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-has-modeline-p'
If you have set `gnus-picons-display-where' to `picons', your
XEmacs frame will become really cluttered. To alleviate this a
bit you can set `gnus-picons-has-modeline-p' to `nil'; this will
remove the mode line from the Picons buffer. This is only useful
if `gnus-picons-display-where' is `picons'.
`gnus-picons-refresh-before-display'
If non-nil, display the article buffer before computing the picons.
Defaults to `nil'.
`gnus-picons-display-as-address'
If `t' display textual email addresses along with pictures.
Defaults to `t'.
`gnus-picons-file-suffixes'
Ordered list of suffixes on picon file names to try. Defaults to
`("xpm" "gif" "xbm")' minus those not builtin your XEmacs.
`gnus-picons-setup-hook'
Hook run in the picon buffer, if that is displayed.
`gnus-picons-display-article-move-p'
Whether to move point to first empty line when displaying picons.
This has only an effect if `gnus-picons-display-where' has value
`article'.
If `nil', display the picons in the `From' and `Newsgroups' lines.
This is the default.
`gnus-picons-clear-cache-on-shutdown'
Whether to clear the picons cache when exiting gnus. Gnus caches
every picons it finds while it is running. This saves some time
in the search process but eats some memory. If this variable is
set to `nil', Gnus will never clear the cache itself; you will
have to manually call `gnus-picons-clear-cache' to clear it.
Otherwise the cache will be cleared every time you exit Gnus.
Defaults to `t'.
File: gnus, Node: Smileys, Next: Toolbar, Prev: Picons, Up: XEmacs Enhancements
Smileys
-------
"Smiley" is a package separate from Gnus, but since Gnus is
currently the only package that uses Smiley, it is documented here.
In short--to use Smiley in Gnus, put the following in your
`.gnus.el' file:
(setq gnus-treat-display-smileys t)
Smiley maps text smiley faces--`:-)', `:-=', `:-(' and the like--to
pictures and displays those instead of the text smiley faces. The
conversion is controlled by a list of regexps that matches text and
maps that to file names.
Smiley supplies two example conversion alists by default:
`smiley-deformed-regexp-alist' (which matches `:)', `:(' and so on),
and `smiley-nosey-regexp-alist' (which matches `:-)', `:-(' and so on).
The alist used is specified by the `smiley-regexp-alist' variable,
which defaults to the value of `smiley-deformed-regexp-alist'.
The first item in each element is the regexp to be matched; the
second element is the regexp match group that is to be replaced by the
picture; and the third element is the name of the file to be displayed.
The following variables customize where Smiley will look for these
files, as well as the color to be used and stuff:
`smiley-data-directory'
Where Smiley will look for smiley faces files.
`smiley-flesh-color'
Skin color. The default is `yellow', which is really racist.
`smiley-features-color'
Color of the features of the face. The default is `black'.
`smiley-tongue-color'
Color of the tongue. The default is `red'.
`smiley-circle-color'
Color of the circle around the face. The default is `black'.
`smiley-mouse-face'
Face used for mouse highlighting over the smiley face.
File: gnus, Node: Toolbar, Next: XVarious, Prev: Smileys, Up: XEmacs Enhancements
Toolbar
-------
`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.
File: gnus, Node: XVarious, Prev: Toolbar, Up: XEmacs Enhancements
Various XEmacs Variables
------------------------
`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. Valid values include `flame', `pine', `moss', `irish',
`sky', `tin', `velvet', `grape', `labia', `berry', `neutral', and
`september'.
`gnus-xmas-modeline-glyph'
A glyph displayed in all Gnus mode lines. It is a tiny gnu head by
default.
File: gnus, Node: Fuzzy Matching, Next: Thwarting Email Spam, Prev: XEmacs Enhancements, Up: Various
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.
File: gnus, Node: Thwarting Email Spam, Next: Various Various, Prev: Fuzzy Matching, Up: Various
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 select the mail
group, only to find two pyramid schemes, seven advertisements ("New!
Miracle tonic for growing full, lustrous 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 (*note Splitting Mail::).
First, pick one (1) valid 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', but for many addresses on the form
`larsi+usenet@ifi.uio.no' will be a better choice. Ask your sysadmin
whether your sendmail installation accepts keywords in the local part
of the mail address.)
(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' (*note
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 thwarting
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.
If you are also a lazy net citizen, you will probably prefer
complaining automatically with the `gnus-junk.el' package, available as
free software at
`http://stud2.tuwien.ac.at/~e9426626/gnus-junk.html'. Since most
e-mail spam is sent automatically, this may reconcile the cosmic
balance somewhat.
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-existent domains is yucky, in my opinion.
File: gnus, Node: Various Various, Prev: Thwarting Email Spam, Up: Various
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.
Note that Gnus is mostly loaded when the `.gnus.el' file is read.
This means that other directory variables that are initialized
from this variable won't be set properly if you set this variable
in `.gnus.el'. Set this variable in `.emacs' instead.
`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 back ends instead of Gnus proper.
`nnheader-max-head-length'
When the back ends read straight heads of articles, they all try
to read as little as possible. This variable (default 4096)
specifies the absolute max length the back ends 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 back ends won't try to read the articles
piece by piece, but read the entire articles. This makes sense
with some versions of `ange-ftp' or `efs'.
`nnheader-head-chop-length'
This variable (default 2048) 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 invalid 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 two shell commands. The default is `;'.
`gnus-invalid-group-regexp'
Regexp to match "invalid" group names when querying user for a
group name. The default value catches some *really* invalid group
names who could possibly mess up Gnus internally (like allowing
`:' in a group name, which is normally used to delimit method and
group).
IMAP users might want to allow `/' in group names though.
File: gnus, Node: The End, Next: Appendices, Prev: Various, Up: Top
The End
*******
Well, that's the manual--you can get on with your life now. Keep in
touch. Say hello to your cats from me.
My *ghod*--I just can't stand goodbyes. Sniffle.
Ol' Charles Reznikoff said it pretty well, so I leave the floor to
him:
*Te Deum*
Not because of victories
I sing,
having none,
but for the common sunshine,
the breeze,
the largess of the spring.
Not for victory
but for the day's work done
as well as I was able;
not for a seat upon the dais
but at the common table.
File: gnus, Node: Appendices, Next: Index, Prev: The End, Up: Top
Appendices
**********
* Menu:
* History:: How Gnus got where it is today.
* On Writing Manuals:: Why this is not a beginner's guide.
* Terminology:: We use really difficult, like, words here.
* Customization:: Tailoring Gnus to your needs.
* Troubleshooting:: What you might try if things do not work.
* Gnus Reference Guide:: Rilly, rilly technical stuff.
* Emacs for Heathens:: A short introduction to Emacsian terms.
* Frequently Asked Questions:: A question-and-answer session.