Info file: gnus, -*-Text-*- produced by `texinfo-format-buffer' from file `gnus.texi' using `texinfmt.el' version 2.32 of 19 November 1993. This file documents Gnus, the GNU Emacs newsreader. Copyright (C) 1995,96 Free Software Foundation, Inc. Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies. Permission is granted to copy and distribute modified versions of this manual under the conditions for verbatim copying, provided also that the entire resulting derived work is distributed under the terms of a permission notice identical to this one. Permission is granted to copy and distribute translations of this manual into another language, under the above conditions for modified versions.  File: gnus, Node: Score File Format, Next: Score File Editing, Prev: Score Variables, Up: Scoring Score File Format ================= A score file is an `emacs-lisp' file that normally contains just a single form. Casual users are not expected to edit these files; everything can be changed from the summary buffer. Anyway, if you'd like to dig into it yourself, here's an example: (("from" ("Lars Ingebrigtsen" -10000) ("Per Abrahamsen") ("larsi\\|lmi" -50000 nil R)) ("subject" ("Ding is Badd" nil 728373)) ("xref" ("alt.politics" -1000 728372 s)) ("lines" (2 -100 nil <)) (mark 0) (expunge -1000) (mark-and-expunge -10) (read-only nil) (orphan -10) (adapt t) (files "/hom/larsi/News/gnu.SCORE") (exclude-files "all.SCORE") (local (gnus-newsgroup-auto-expire t) (gnus-summary-make-false-root 'empty)) (eval (ding))) This example demonstrates absolutely everything about a score file. Even though this looks much like lisp code, nothing here is actually `eval'ed. The lisp reader is used to read this form, though, so it has to be legal syntactically, if not semantically. Six keys are supported by this alist: `STRING' If the key is a string, it is the name of the header to perform the match on. Scoring can only be performed on these eight headers: `From', `Subject', `References', `Message-ID', `Xref', `Lines', `Chars' and `Date'. In addition to these headers, there are three strings to tell Gnus to fetch the entire article and do the match on larger parts of the article: `Body' will perform the match on the body of the article, `Head' will perform the match on the head of the article, and `All' will perform the match on the entire article. Note that using any of these last three keys will slow down group entry *considerably*. The final "header" you can score on is `Followup'. These score entries will result in new score entries being added for all follow-ups to articles that matches these score entries. Following this key is a arbitrary number of score entries, where each score entry has one to four elements. 1. The first element is the "match element". On most headers this will be a string, but on the Lines and Chars headers, this must be an integer. 2. If the second element is present, it should be a number--the "score element". This number should be an integer in the neginf to posinf interval. This number is added to the score of the article if the match is successful. If this element is not present, the `gnus-score-interactive-default-score' number will be used instead. This is 1000 by default. 3. If the third element is present, it should be a number--the "date element". This date says when the last time this score entry matched, which provides a mechanism for expiring the score entries. It this element is not present, the score entry is permanent. The date is represented by the number of days since December 31, 1 ce. 4. If the fourth element is present, it should be a symbol--the "type element". This element specifies what function should be used to see whether this score entry matches the article. What match types that can be used depends on what header you wish to perform the match on. "From, Subject, References, Xref, Message-ID" For most header types, there are the `r' and `R' (regexp) as well as `s' and `S' (substring) types and `e' and `E' (exact match) types. If this element is not present, Gnus will assume that substring matching should be used. `R' and `S' differ from the other two in that the matches will be done in a case-sensitive manner. All these one-letter types are really just abbreviations for the `regexp', `string' and `exact' types, which you can use instead, if you feel like. "Lines, Chars" These two headers use different match types: `<', `>', `=', `>=' and `<='. "Date" For the Date header we have three match types: `before', `at' and `after'. I can't really imagine this ever being useful, but, like, it would feel kinda silly not to provide this function. Just in case. You never know. Better safe than sorry. Once burnt, twice shy. Don't judge a book by its cover. Never not have sex on a first date. (I have been told that at least one person, and I quote, "found this function indispensable", however.) "Head, Body, All" These three match keys use the same match types as the `From' (etc) header uses. "Followup" This match key will add a score entry on all articles that followup to some author. Uses the same match types as the `From' header uses. "Thread" This match key will add a score entry on all articles that are part of a thread. Uses the same match types as the `References' header uses. `mark' The value of this entry should be a number. Any articles with a score lower than this number will be marked as read. `expunge' The value of this entry should be a number. Any articles with a score lower than this number will be removed from the summary buffer. `mark-and-expunge' The value of this entry should be a number. Any articles with a score lower than this number will be marked as read and removed from the summary buffer. `thread-mark-and-expunge' The value of this entry should be a number. All articles that belong to a thread that has a total score below this number will be marked as read and removed from the summary buffer. `gnus-thread-score-function' says how to compute the total score for a thread. `files' The value of this entry should be any number of file names. These files are assumed to be score files as well, and will be loaded the same way this one was. `exclude-files' The clue of this entry should be any number of files. This files will not be loaded, even though they would normally be so, for some reason or other. `eval' The value of this entry will be `eval'el. This element will be ignored when handling global score files. `read-only' Read-only score files will not be updated or saved. Global score files should feature this atom (*Note Global Score Files::). `orphan' The value of this entry should be a number. Articles that do not have parents will get this number added to their scores. Imagine you follow some high-volume newsgroup, like `comp.lang.c'. Most likely you will only follow a few of the threads, also want to see any new threads. You can do this with the following two score file entries: (orphan -500) (mark-and-expunge -100) When you enter the group the first time, you will only see the new threads. You then raise the score of the threads that you find interesting (with `I T' or `I S'), and ignore (`C y') the rest. Next time you enter the group, you will see new articles in the interesting threads, plus any new threads. I.e. -- the orphan score atom is for high-volume groups where there exist a few interesting threads which can't be found automatically by ordinary scoring rules. `adapt' This entry controls the adaptive scoring. If it is `t', the default adaptive scoring rules will be used. If it is `ignore', no adaptive scoring will be performed on this group. If it is a list, this list will be used as the adaptive scoring rules. If it isn't present, or is something other than `t' or `ignore', the default adaptive scoring rules will be used. If you want to use adaptive scoring on most groups, you'd set `gnus-use-adaptive-scoring' to `t', and insert an `(adapt ignore)' in the groups where you do not want adaptive scoring. If you only want adaptive scoring in a few groups, you'd set `gnus-use-adaptive-scoring' to `nil', and insert `(adapt t)' in the score files of the groups where you want it. `adapt-file' All adaptive score entries will go to the file named by this entry. It will also be applied when entering the group. This atom might be handy if you want to adapt on several groups at once, using the same adaptive file for a number of groups. `local' The value of this entry should be a list of `(VAR VALUE)' pairs. Each VAR will be made buffer-local to the current summary buffer, and set to the value specified. This is a convenient, if somewhat strange, way of setting variables in some groups if you don't like hooks much.  File: gnus, Node: Score File Editing, Next: Adaptive Scoring, Prev: Score File Format, Up: Scoring Score File Editing ================== You normally enter all scoring commands from the summary buffer, but you might feel the urge to edit them by hand as well, so we've supplied you with a mode for that. It's simply a slightly customized `emacs-lisp' mode, with these additional commands: `C-c C-c' Save the changes you have made and return to the summary buffer (`gnus-score-edit-done'). `C-c C-d' Insert the current date in numerical format (`gnus-score-edit-insert-date'). This is really the day number, if you were wondering. `C-c C-p' The adaptive score files are saved in an unformatted fashion. If you intend to read one of these files, you want to "pretty print" it first. This command (`gnus-score-pretty-print') does that for you. Type `M-x gnus-score-mode' to use this mode. `gnus-score-menu-hook' is run in score mode buffers. In the summary buffer you can use commands like `V f' and `V e' to begin editing score files.  File: gnus, Node: Adaptive Scoring, Next: Followups To Yourself, Prev: Score File Editing, Up: Scoring Adaptive Scoring ================ If all this scoring is getting you down, Gnus has a way of making it all happen automatically--as if by magic. Or rather, as if by artificial stupidity, to be precise. When you read an article, or mark an article as read, or kill an article, you leave marks behind. On exit from the group, Gnus can sniff these marks and add score elements depending on what marks it finds. You turn on this ability by setting `gnus-use-adaptive-scoring' to `t'. To give you complete control over the scoring process, you can customize the `gnus-default-adaptive-score-alist' variable. For instance, it might look something like this: (defvar gnus-default-adaptive-score-alist '((gnus-unread-mark) (gnus-ticked-mark (from 4)) (gnus-dormant-mark (from 5)) (gnus-del-mark (from -4) (subject -1)) (gnus-read-mark (from 4) (subject 2)) (gnus-expirable-mark (from -1) (subject -1)) (gnus-killed-mark (from -1) (subject -3)) (gnus-kill-file-mark) (gnus-ancient-mark) (gnus-low-score-mark) (gnus-catchup-mark (from -1) (subject -1)))) As you see, each element in this alist has a mark as a key (either a variable name or a "real" mark--a character). Following this key is a arbitrary number of header/score pairs. If there are no header/score pairs following the key, no adaptive scoring will be done on articles that have that key as the article mark. For instance, articles with `gnus-unread-mark' in the example above will not get adaptive score entries. Each article can have only one mark, so just a single of these rules will be applied to each article. To take `gnus-del-mark' as an example--this alist says that all articles that have that mark (i.e., are marked with `D') will have a score entry added to lower based on the `From' header by -4, and lowered by `Subject' by -1. Change this to fit your prejudices. If you have marked 10 articles with the same subject with `gnus-del-mark', the rule for that mark will be applied ten times. That means that that subject will get a score of ten times -1, which should be, unless I'm much mistaken, -10. The headers you can score on are `from', `subject', `message-id', `references', `xref', `lines', `chars' and `date'. In addition, you can score on `followup', which will create an adaptive score entry that matches on the `References' header using the `Message-ID' of the current article, thereby matching the following thread. You can also score on `thread', which will try to score all articles that appear in a thread. `thread' matches uses a `Message-ID' to match on the `References' header of the article. If the match is made, the `Message-ID' of the article is added to the `thread' rule. (Think about it. I'd recommend two aspirins afterwards.) If you use this scheme, you should set the score file atom `mark' to something small--like -300, perhaps, to avoid having small random changes result in articles getting marked as read. After using adaptive scoring for a week or so, Gnus should start to become properly trained and enhance the authors you like best, and kill the authors you like least, without you having to say so explicitly. You can control what groups the adaptive scoring is to be performed on by using the score files (*Note Score File Format::). This will also let you use different rules in different groups. The adaptive score entries will be put into a file where the name is the group name with `gnus-adaptive-file-suffix' appended. The default is `ADAPT'. When doing adaptive scoring, substring or fuzzy matching would probably give you the best results in most cases. However, if the header one matches is short, the possibility for false positives is great, so if the length of the match is less than `gnus-score-exact-adapt-limit', exact matching will be used. If this variable is `nil', exact matching will always be used to avoid this problem.  File: gnus, Node: Followups To Yourself, Next: Scoring Tips, Prev: Adaptive Scoring, Up: Scoring Followups To Yourself ===================== Gnus offers two commands for picking out the `Message-ID' header in the current buffer. Gnus will then add a score rule that scores using this `Message-ID' on the `References' header of other articles. This will, in effect, increase the score of all articles that respond to the article in the current buffer. Quite useful if you want to easily note when people answer what you've said. `gnus-score-followup-article' This will add a score to articles that directly follow up your own article. `gnus-score-followup-thread' This will add a score to all articles that appear in a thread "below" your own article. These two functions are both primarily meant to be used in hooks like `message-send-hook'.  File: gnus, Node: Scoring Tips, Next: Reverse Scoring, Prev: Followups To Yourself, Up: Scoring Scoring Tips ============ "Crossposts" If you want to lower the score of crossposts, the line to match on is the `Xref' header. ("xref" (" talk.politics.misc:" -1000)) "Multiple crossposts" If you want to lower the score of articles that have been crossposted to more than, say, 3 groups: ("xref" ("[^:\n]+:[0-9]+ +[^:\n]+:[0-9]+ +[^:\n]+:[0-9]+" -1000 nil r)) "Matching on the body" This is generally not a very good idea--it takes a very long time. Gnus actually has to fetch each individual article from the server. But you might want to anyway, I guess. Even though there are three match keys (`Head', `Body' and `All'), you should choose one and stick with it in each score file. If you use any two, each article will be fetched *twice*. If you want to match a bit on the `Head' and a bit on the `Body', just use `All' for all the matches. "Marking as read" You will probably want to mark articles that has a score below a certain number as read. This is most easily achieved by putting the following in your `all.SCORE' file: ((mark -100)) You may also consider doing something similar with `expunge'. "Negated character classes" If you say stuff like `[^abcd]*', you may get unexpected results. That will match newlines, which might lead to, well, The Unknown. Say `[^abcd\n]*' instead.  File: gnus, Node: Reverse Scoring, Next: Global Score Files, Prev: Scoring Tips, Up: Scoring Reverse Scoring =============== If you want to keep just articles that have `Sex with Emacs' in the subject header, and expunge all other articles, you could put something like this in your score file: (("subject" ("Sex with Emacs" 2)) (mark 1) (expunge 1)) So, you raise all articles that match `Sex with Emacs' and mark the rest as read, and expunge them to boot.  File: gnus, Node: Global Score Files, Next: Kill Files, Prev: Reverse Scoring, Up: Scoring Global Score Files ================== Sure, other newsreaders have "global kill files". These are usually nothing more than a single kill file that applies to all groups, stored in the user's home directory. Bah! Puny, weak newsreaders! What I'm talking about here are Global Score Files. Score files from all over the world, from users everywhere, uniting all nations in one big, happy score file union! Ange-score! New and untested! All you have to do to use other people's score files is to set the `gnus-global-score-files' variable. One entry for each score file, or each score file directory. Gnus will decide by itself what score files are applicable to which group. Say you want to use all score files in the `/ftp@ftp.some-where:/pub/score' directory and the single score file `/ftp@ftp.ifi.uio.no:/pub/larsi/ding/score/soc.motss.SCORE': (setq gnus-global-score-files '("/ftp@ftp.ifi.uio.no:/pub/larsi/ding/score/soc.motss.SCORE" "/ftp@ftp.some-where:/pub/score/")) Simple, eh? Directory names must end with a `/'. These directories are typically scanned only once during each Gnus session. If you feel the need to manually re-scan the remote directories, you can use the `gnus-score-search-global-directories' command. Note that, at present, using this option will slow down group entry somewhat. (That is--a lot.) If you want to start maintaining score files for other people to use, just put your score file up for anonymous ftp and announce it to the world. Become a retro-moderator! Participate in the retro-moderator wars sure to ensue, where retro-moderators battle it out for the sympathy of the people, luring them to use their score files on false premises! Yay! The net is saved! Here are some tips for the would-be retro-moderator, off the top of my head: * Articles that are heavily crossposted are probably junk. * To lower a single inappropriate article, lower by `Message-ID'. * Particularly brilliant authors can be raised on a permanent basis. * Authors that repeatedly post off-charter for the group can safely be lowered out of existence. * Set the `mark' and `expunge' atoms to obliterate the nastiest articles completely. * Use expiring score entries to keep the size of the file down. You should probably have a long expiry period, though, as some sites keep old articles for a long time. ... I wonder whether other newsreaders will support global score files in the future. *Snicker*. Yup, any day now, newsreaders like Blue Wave, xrn and 1stReader are bound to implement scoring. Should we start holding our breath yet?  File: gnus, Node: Kill Files, Next: GroupLens, Prev: Global Score Files, Up: Scoring Kill Files ========== Gnus still supports those pesky old kill files. In fact, the kill file entries can now be expiring, which is something I wrote before Daniel Quinlan thought of doing score files, so I've left the code in there. In short, kill processing is a lot slower (and I do mean *a lot*) than score processing, so it might be a good idea to rewrite your kill files into score files. Anyway, a kill file is a normal `emacs-lisp' file. You can put any forms into this file, which means that you can use kill files as some sort of primitive hook function to be run on group entry, even though that isn't a very good idea. XCNormal kill files look like this: (gnus-kill "From" "Lars Ingebrigtsen") (gnus-kill "Subject" "ding") (gnus-expunge "X") This will mark every article written by me as read, and remove them from the summary buffer. Very useful, you'll agree. Other programs use a totally different kill file syntax. If Gnus encounters what looks like a `rn' kill file, it will take a stab at interpreting it. Two summary functions for editing a GNUS kill file: `M-k' Edit this group's kill file (`gnus-summary-edit-local-kill'). `M-K' Edit the general kill file (`gnus-summary-edit-global-kill'). Two group mode functions for editing the kill files: `M-k' Edit this group's kill file (`gnus-group-edit-local-kill'). `M-K' Edit the general kill file (`gnus-group-edit-global-kill'). Kill file variables: `gnus-kill-file-name' A kill file for the group `soc.motss' is normally called `soc.motss.KILL'. The suffix appended to the group name to get this file name is detailed by the `gnus-kill-file-name' variable. The "global" kill file (not in the score file sense of "global", of course) is called just `KILL'. `gnus-kill-save-kill-file' If this variable is non-`nil', Gnus will save the kill file after processing, which is necessary if you use expiring kills. `gnus-apply-kill-hook' A hook called to apply kill files to a group. It is `(gnus-apply-kill-file)' by default. If you want to ignore the kill file if you have a score file for the same group, you can set this hook to `(gnus-apply-kill-file-unless-scored)'. If you don't want kill files to be processed, you should set this variable to `nil'. `gnus-kill-file-mode-hook' A hook called in kill-file mode buffers.  File: gnus, Node: GroupLens, Prev: Kill Files, Up: Scoring GroupLens ========= GroupLens is a collaborative filtering system that helps you work together with other people to find the quality news articles out of the huge volume of news articles generated every day. To accomplish this the GroupLens system combines your opinions about articles you have already read with the opinions of others who have done likewise and gives you a personalized prediction for each unread news article. Think of GroupLens as a matchmaker. GroupLens watches how you rate articles, and finds other people that rate articles the same way. Once it has found for you some people you agree with it tells you, in the form of a prediction, what they thought of the article. You can use this prediction to help you decide whether or not you want to read the article. * Menu: * Using GroupLens:: How to make Gnus use GroupLens. * Rating Articles:: Letting GroupLens know how you rate articles. * Displaying Predictions:: Displaying predictions given by GroupLens. * GroupLens Variables:: Customizing GroupLens.  File: gnus, Node: Using GroupLens, Next: Rating Articles, Prev: GroupLens, Up: GroupLens Using GroupLens --------------- To use GroupLens you must register a pseudonym with your local Better Bit Bureau (BBB). At the moment the only better bit in town is at `http://www.cs.umn.edu/Research/GroupLens/bbb.html'. Once you have registered you'll need to set a couple of variables. `gnus-use-grouplens' Setting this variable to a non-`nil' value will make Gnus hook into all the relevant GroupLens functions. `grouplens-pseudonym' This variable should be set to the pseudonum you got when registering with the Better Bit Bureau. `grouplens-newsgroups' A list of groups that you want to get GroupLens predictions for. Thats the minimum of what you need to get up and running with GroupLens. Once you've registered, GroupLens will start giving you scores for articles based on the average of what other people think. But, to get the real benefit of GroupLens you need to start rating articles yourself. Then the scores GroupLens gives you will be personalized for you, based on how the people you usually agree with have already rated.  File: gnus, Node: Rating Articles, Next: Displaying Predictions, Prev: Using GroupLens, Up: GroupLens Rating Articles --------------- In GroupLens, an article is rated on a scale from 1 to 5, inclusive. Where 1 means something like this article is a waste of bandwidth and 5 means that the article was really good. The basic question to ask yourself is, "on a scale from 1 to 5 would I like to see more articles like this one?" There are four ways to enter a rating for an article in GroupLens. `r' This function will prompt you for a rating on a scale of one to five. `k' This function will prompt you for a rating, and rate all the articles in the thread. This is really useful for some of those long running giant threads in rec.humor. The next two commands, `n' and `,' take a numerical prefix to be the score of the article you're reading. `1-5 n' Rate the article and go to the next unread article. `1-5 ,' Rate the article and go to the next unread article with the highest score. If you want to give the current article a score of 4 and then go to the next article, just type `4 n'.  File: gnus, Node: Displaying Predictions, Next: GroupLens Variables, Prev: Rating Articles, Up: GroupLens Displaying Predictions ---------------------- GroupLens makes a prediction for you about how much you will like a news article. The predictions from GroupLens are on a scale from 1 to 5, where 1 is the worst and 5 is the best. You can use the predictions from GroupLens in one of three ways controlled by the variable `gnus-grouplens-override-scoring'. There are three ways to display predictions in grouplens. You may choose to have the GroupLens scores contribute to, or override the regular gnus scoring mechanism. override is the default; however, some people prefer to see the Gnus scores plus the grouplens scores. To get the separate scoring behavior you need to set `gnus-grouplens-override-scoring' to `'separate'. To have the GroupLens predictions combined with the grouplens scores set it to `'override' and to combine the scores set `gnus-grouplens-override-scoring' to `'combine'. When you use the combine option you will also want to set the values for `grouplens-prediction-offset' and `grouplens-score-scale-factor'. In either case, GroupLens gives you a few choices for how you would like to see your predictions displayed. The display of predictions is controlled by the `grouplens-prediction-display' variable. The following are legal values for that variable. `prediction-spot' The higher the prediction, the further to the right an `*' is displayed. `confidence-interval' A numeric confidence interval. `prediction-bar' The higher the prediction, the longer the bar. `confidence-bar' Numerical confidence. `confidence-spot' The spot gets bigger with more confidence. `prediction-num' Plain-old numeric value. `confidence-plus-minus' Prediction +/i confidence.  File: gnus, Node: GroupLens Variables, Prev: Displaying Predictions, Up: GroupLens GroupLens Variables ------------------- `gnus-summary-grouplens-line-format' The summary line format used in summary buffers that are GroupLens enhanced. It accepts the same specs as the normal summary line format (*Note Summary Buffer Lines::). The default is `%U%R%z%l%I%(%[%4L: %-20,20n%]%) %s\n'. `grouplens-bbb-host' Host running the bbbd server. The default is `grouplens.cs.umn.edu'. `grouplens-bbb-port' Port of the host running the bbbd server. The default is 9000. `grouplens-score-offset' Offset the prediction by this value. In other words, subtract the prediction value by this number to arrive at the effective score. The default is 0. `grouplens-score-scale-factor' This variable allows the user to magnify the effect of GroupLens scores. The scale factor is applied after the offset. The default is 1.  File: gnus, Node: Various, Next: The End, Prev: Scoring, Up: Top Various ******* * Menu: * Process/Prefix:: A convention used by many treatment commands. * Interactive:: Making Gnus ask you many questions. * Formatting Variables:: You can specify what buffers should look like. * Windows Configuration:: Configuring the Gnus buffer windows. * Compilation:: How to speed Gnus up. * Mode Lines:: Displaying information in the mode lines. * Highlighting and Menus:: Making buffers look all nice and cozy. * Buttons:: Get tendonitis in ten easy steps! * Daemons:: Gnus can do things behind your back. * NoCeM:: How to avoid spam and other fatty foods. * Picons:: How to display pictures of what your reading. * Various Various:: Things that are really various.  File: gnus, Node: Process/Prefix, Next: Interactive, Prev: Various, Up: 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. 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.  File: gnus, Node: Interactive, Next: Formatting Variables, Prev: Process/Prefix, Up: Various 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.  File: gnus, Node: Formatting Variables, Next: Windows Configuration, Prev: Interactive, Up: Various 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. 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". Just like a normal format spec, almost. You can also say `%6,4y', which means that the field will never be more than 4 characters wide and never less than 6 characters wide. There are also 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! 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'. Note that the `%(' specs (and friends) do not make any sense on the mode-line variables. 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.  File: gnus, Node: Windows Configuration, Next: Compilation, 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. `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 `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 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. *Note Frame Parameters: (elisp)Frame Parameters. Here's a list of all possible keys for `gnus-buffer-configuration': `group', `summary', `article', `server', `browse', `group-mail', `summary-mail', `summary-reply', `info', `summary-faq', `edit-group', `edit-server', `reply', `reply-yank', `followup', `followup-yank', `edit-score'. 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' file or in some startup hook -- they should be run after Gnus has been loaded.  File: gnus, Node: Compilation, Next: Mode Lines, Prev: Windows Configuration, 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.  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 (eg. 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 (eg. 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.  File: gnus, Node: Highlighting and Menus, Next: Buttons, Prev: Mode Lines, Up: Various 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'. `gnus-display-type' This variable is symbol indicating the display type Emacs is running under. The symbol should be one of `color', `grayscale' or `mono'. If Gnus guesses this display attribute wrongly, either set this variable in your `~/.emacs' or set the resource `Emacs.displayType' in your `~/.Xdefaults'. `gnus-background-mode' This is a symbol indicating the Emacs background brightness. The symbol should be one of `light' or `dark'. If Gnus guesses this frame attribute wrongly, either set this variable in your `~/.emacs' or set the resource `Emacs.backgroundMode' in your `~/.Xdefaults'. `gnus-display-type'. 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 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.  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 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', 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.