Go to the first, previous, next, last section, table of contents.
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 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 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.
gnus-novice-user
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
nil
, you will seldom be asked any
questions by Gnus. It will simply assume you know what you're doing, no
matter how strange.
gnus-interactive-catchup
nil
. It
is t
by default.
gnus-interactive-exit
t
by
default.
Quite a lot of Emacs commands react to the (numeric) prefix. For
instance, C-u 4 C-f moves point four characters forward, and
C-u 9 0 0 I s s p adds a permanent Subject
substring score
rule of 900 to the current article.
This is all nice and well, but what if you want to give a command some additional information? Well, what most commands do is interpret the "raw" prefix in some special way. C-u 0 C-x C-s means that one doesn't want a backup file to be created when saving the current buffer, for instance. But what if you want to save without making a backup file, and you want Emacs to flash lights and play a nice tune at the same time? You can't, and you're probably perfectly happy that way.
I'm not, so I've added a second prefix--the symbolic prefix. The
prefix key is M-i (gnus-symbolic-argument
), and the next
character typed in is the value. You can stack as many M-i
prefixes as you want. M-i a M-C-u means "feed the M-C-u
command the symbolic prefix a
". M-i a M-i b M-C-u means
"feed the M-C-u command the symbolic prefixes a
and
b
". You get the drift.
Typing in symbolic prefixes to commands that don't accept them doesn't hurt, but it doesn't do any good either. Currently not many Gnus functions make use of the symbolic prefix.
If you're interested in how Gnus implements this, see section Extended Interactive.
Throughout this manual you've probably noticed lots of variables 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 eval
ed 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.
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.
Mode line formatting variables (e.g.,
gnus-summary-mode-line-format
) follow the same rules as other,
buffer line oriented formatting variables (see section Formatting Basics)
with the following two differences:
mode-line-format
variable.
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 valid modifiers:
pad
pad-left
pad-right
max
max-left
max-right
cut
cut-left
cut-right
ignore
form
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.
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.
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{', 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.
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
. 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 = "(" buffer-name " " size *[ "point" ] *[ "frame-focus"] ")" 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 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.
See section `Frame Parameters' in The GNU Emacs Lisp Reference Manual. Under XEmacs, a frame property list will be
accepted, too--for instance, (height 5 width 15 left -1 top 1)
is such a plist.
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
, and score-trace
.
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
.
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.
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.)
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.
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
summary-highlight
article-highlight
highlight
group-menu
summary-menu
article-menu
browse-menu
server-menu
score-menu
menu
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
gnus-visual
is nil
.
There are hooks associated with the creation of all the different menus:
gnus-article-menu-hook
gnus-group-menu-hook
gnus-summary-menu-hook
gnus-server-menu-hook
gnus-browse-menu-hook
gnus-score-menu-hook
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
gnus-carpal-button-face
gnus-carpal-header-face
gnus-carpal-group-buffer-buttons
gnus-carpal-summary-buffer-buttons
gnus-carpal-server-buffer-buttons
gnus-carpal-browse-buffer-buttons
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.
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.)
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 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.
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
t
to set the ball rolling. It is nil
by default.
gnus-nocem-groups
("news.lists.filters" "news.admin.net-abuse.bulletins"
"alt.nocem.misc" "news.admin.net-abuse.announce")
.
gnus-nocem-issuers
("Automoose-1"
"rbraver@ohww.norman.ok.us" "clewis@ferret.ocunix.on.ca"
"jem@xpat.com" "snowhare@xmission.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:
(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
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
gnus-nocem-expiry-wait
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 (see section Subscription Commands).
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
command, which should feel kinda like the normal Emacs undo
command.
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:
To use moderation mode in these two groups, say:
(setq gnus-moderated-list "^nnml:rec.zoofle$\\|^rec.zoofle$")
XEmacs is able to display pictures and stuff, so Gnus has taken advantage of that.
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.
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 colorXPM
andGIF
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
.
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.
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-article-display-hook 'gnus-picons-article-display-x-face)
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")
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
gnus-picons-piconsearch-url
is nil
. Defaults to
`/usr/local/faces/'.
gnus-picons-piconsearch-url
nil
'the default), then picons are fetched from local
database indicated by gnus-picons-database
.
gnus-picons-display-where
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.
gnus-picons-group-excluded-groups
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
gnus-picons-display-where
buffer. Should be added to the
gnus-article-display-hook
.
gnus-picons-article-display-x-face
gnus-article-display-hook
.
Note: You must append them to the hook, so make sure to specify 't'
for the append flag of add-hook
:
(add-hook 'gnus-article-display-hook 'gnus-article-display-picons t)
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
gnus-picons-database
for
newsgroups faces. ("news")
is the default.
gnus-picons-user-directories
gnus-picons-database
for user
faces. ("local" "users" "usenix" "misc")
is the default.
gnus-picons-domain-directories
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
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
X-Face
bitmap in. Defaults
to (format "/tmp/picon-xface.%s.xbm" (user-login-name))
.
gnus-picons-has-modeline-p
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
nil
.
gnus-picons-display-as-address
t
display textual email addresses along with pictures.
Defaults to t
.
gnus-picons-file-suffixes
("xpm" "gif" "xbm")
minus those not builtin your XEmacs.
gnus-picons-display-article-move-p
gnus-picons-clear-cache-on-shutdown
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
.
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:
(add-hook 'gnus-article-display-hook 'gnus-smiley-display 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
smiley-flesh-color
smiley-features-color
smiley-tongue-color
smiley-circle-color
smiley-mouse-face
gnus-use-toolbar
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
gnus-summary-toolbar
gnus-summary-mail-toolbar
gnus-xmas-glyph-directory
gnus-xmas-logo-color-alist
gnus-xmas-logo-color-style
flame
, pine
, moss
,
irish
, sky
, tin
, velvet
, grape
,
labia
, berry
, neutral
, and september
.
gnus-xmas-modeline-glyph
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.
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 (see section 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
sysadm 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
(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
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 FOR FREE
at
`<URL: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.
gnus-home-directory
gnus-directory
gnus-default-directory
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
gnus-verbose-backends
gnus-verbose
, but it applies
to the Gnus backends instead of Gnus proper.
nnheader-max-head-length
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
or efs
.
nnheader-head-chop-length
nnheader-file-name-translation-alist
(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
(invisible t intangible t)
by default on most systems, which
makes invisible text invisible and intangible.
gnus-parse-headers-hook
gnus-shell-command-separator
Go to the first, previous, next, last section, table of contents.