html2
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
10.1 History How Gnus got where it is today. 10.2 On Writing Manuals Why this is not a beginner's guide. 10.3 Terminology We use really difficult, like, words here. 10.4 Customization Tailoring Gnus to your needs. 10.5 Troubleshooting What you might try if things do not work. 10.6 Gnus Reference Guide Rilly, rilly technical stuff. 10.7 Emacs for Heathens A short introduction to Emacsian terms. 10.8 Frequently Asked Questions A question-and-answer session.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
GNUS was written by Masanobu UMEDA. When autumn crept up in '94, Lars Magne Ingebrigtsen grew bored and decided to rewrite Gnus.
If you want to investigate the person responsible for this outrage, you can point your (feh!) web browser to `http://quimby.gnus.org/~larsi/'. This is also the primary distribution point for the new and spiffy versions of Gnus, and is known as The Site That Destroys Newsrcs And Drives People Mad.
During the first extended alpha period of development, the new Gnus was called "(ding) Gnus". (ding) is, of course, short for ding is not Gnus, which is a total and utter lie, but who cares? (Besides, the "Gnus" in this abbreviation should probably be pronounced "news" as UMEDA intended, which makes it a more appropriate name, don't you think?)
In any case, after spending all that energy on coming up with a new and spunky name, we decided that the name was too spunky, so we renamed it back again to "Gnus". But in mixed case. "Gnus" vs. "GNUS". New vs. old.
10.1.1 Gnus Versions What Gnus versions have been released. 10.1.2 Other Gnus Versions Other Gnus versions that also have been released. 10.1.3 Why? What's the point of Gnus? 10.1.4 Compatibility Just how compatible is Gnus with GNUS? 10.1.5 Conformity Gnus tries to conform to all standards. 10.1.6 Emacsen Gnus can be run on a few modern Emacsen. 10.1.7 Gnus Development How Gnus is developed. 10.1.8 Contributors Oodles of people. 10.1.9 New Features Pointers to some of the new stuff in Gnus. 10.1.10 Newest Features Features so new that they haven't been written yet.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The first "proper" release of Gnus 5 was done in November 1995 when it was included in the Emacs 19.30 distribution (132 (ding) Gnus releases plus 15 Gnus 5.0 releases).
In May 1996 the next Gnus generation (aka. "September Gnus" (after 99 releases)) was released under the name "Gnus 5.2" (40 releases).
On July 28th 1996 work on Red Gnus was begun, and it was released on January 25th 1997 (after 84 releases) as "Gnus 5.4" (67 releases).
On September 13th 1997, Quassia Gnus was started and lasted 37 releases. If was released as "Gnus 5.6" on March 8th 1998 (46 releases).
Gnus 5.6 begat Pterodactyl Gnus on August 29th 1998 and was released as "Gnus 5.8" (after 99 releases and a CVS repository) on December 3rd 1999.
If you happen upon a version of Gnus that has a prefixed name -- "(ding) Gnus", "September Gnus", "Red Gnus", "Quassia Gnus" -- don't panic. Don't let it know that you're frightened. Back away. Slowly. Whatever you do, don't run. Walk away, calmly, until you're out of its reach. Find a proper released version of Gnus and snuggle up to that instead.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
In addition to the versions of Gnus which have had their releases coordinated by Lars, one major development has been Semi-gnus from Japan. It's based on a library called SEMI, which provides MIME capabilities.
These Gnusae are based mainly on Gnus 5.6 and Pterodactyl Gnus. Collectively, they are called "Semi-gnus", and different strains are called T-gnus, ET-gnus, Nana-gnus and Chaos. These provide powerful MIME and multilingualization things, especially important for Japanese users.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
What's the point of Gnus?
I want to provide a "rad", "happening", "way cool" and "hep" newsreader, that lets you do anything you can think of. That was my original motivation, but while working on Gnus, it has become clear to me that this generation of newsreaders really belong in the stone age. Newsreaders haven't developed much since the infancy of the net. If the volume continues to rise with the current rate of increase, all current newsreaders will be pretty much useless. How do you deal with newsgroups that have thousands of new articles each day? How do you keep track of millions of people who post?
Gnus offers no real solutions to these questions, but I would very much like to see Gnus being used as a testing ground for new methods of reading and fetching news. Expanding on UMEDA-san's wise decision to separate the newsreader from the backends, Gnus now offers a simple interface for anybody who wants to write new backends for fetching mail and news from different sources. I have added hooks for customizations everywhere I could imagine it being useful. By doing so, I'm inviting every one of you to explore and invent.
May Gnus never be complete. C-u 100 M-x all-hail-emacs and C-u 100 M-x all-hail-xemacs.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Gnus was designed to be fully compatible with GNUS. Almost all key bindings have been kept. More key bindings have been added, of course, but only in one or two obscure cases have old bindings been changed.
Our motto is:
In a cloud bones of steel.
All commands have kept their names. Some internal functions have changed their names.
The gnus-uu
package has changed drastically. See section 3.15 Decoding Articles.
One major compatibility question is the presence of several summary buffers. All variables relevant while reading a group are buffer-local to the summary buffer they belong in. Although many important variables have their values copied into their global counterparts whenever a command is executed in the summary buffer, this change might lead to incorrect values being used unless you are careful.
All code that relies on knowledge of GNUS internals will probably
fail. To take two examples: Sorting gnus-newsrc-alist
(or
changing it in any way, as a matter of fact) is strictly verboten. Gnus
maintains a hash table that points to the entries in this alist (which
speeds up many functions), and changing the alist directly will lead to
peculiar results.
Old hilit19 code does not work at all. In fact, you should probably
remove all hilit code from all Gnus hooks
(gnus-group-prepare-hook
and gnus-summary-prepare-hook
).
Gnus provides various integrated functions for highlighting. These are
faster and more accurate. To make life easier for everybody, Gnus will
by default remove all hilit calls from all hilit hooks. Uncleanliness!
Away!
Packages like expire-kill
will no longer work. As a matter of
fact, you should probably remove all old GNUS packages (and other
code) when you start using Gnus. More likely than not, Gnus already
does what you have written code to make GNUS do. (Snicker.)
Even though old methods of doing things are still supported, only the new methods are documented in this manual. If you detect a new method of doing something while reading this manual, that does not mean you have to stop doing it the old way.
Gnus understands all GNUS startup files.
Overall, a casual user who hasn't written much code that depends on GNUS internals should suffer no problems. If problems occur, please let me know by issuing that magic command M-x gnus-bug.
If you are in the habit of sending bug reports very often, you
may find the helpful help buffer annoying after a while. If so, set
gnus-bug-create-help-buffer
to nil
to avoid having it pop
up at you.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
No rebels without a clue here, ma'am. We conform to all standards known to (wo)man. Except for those standards and/or conventions we disagree with, of course.
tin
and Netscape
I know not to use
either of those for posting articles. I would not have known that if
it wasn't for the X-Newsreader
header.
If you ever notice Gnus acting non-compliant with regards to the texts mentioned above, don't hesitate to drop a note to Gnus Towers and let us know.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Gnus should work on :
This Gnus version will absolutely not work on any Emacsen older than that. Not reliably, at least. Older versions of Gnus may work on older Emacs versions.
There are some vague differences between Gnus on the various platforms--XEmacs features more graphics (a logo and a toolbar)---but other than that, things should look pretty much the same under all Emacsen.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Gnus is developed in a two-phased cycle. The first phase involves much discussion on the `ding@gnus.org' mailing list, where people propose changes and new features, post patches and new backends. This phase is called the alpha phase, since the Gnusae released in this phase are alpha releases, or (perhaps more commonly in other circles) snapshots. During this phase, Gnus is assumed to be unstable and should not be used by casual users. Gnus alpha releases have names like "Red Gnus" and "Quassia Gnus".
After futzing around for 50-100 alpha releases, Gnus is declared frozen, and only bug fixes are applied. Gnus loses the prefix, and is called things like "Gnus 5.6.32" instead. Normal people are supposed to be able to use these, and these are mostly discussed on the `gnu.emacs.gnus' newsgroup.
Some variable defaults differ between alpha Gnusae and released Gnusae.
In particular, mail-source-delete-incoming
defaults to nil
in
alpha Gnusae and t
in released Gnusae. This is to prevent
lossage of mail if an alpha release hiccups while handling the mail.
The division of discussion between the ding mailing list and the Gnus newsgroup is not purely based on publicity concerns. It's true that having people write about the horrible things that an alpha Gnus release can do (sometimes) in a public forum may scare people off, but more importantly, talking about new experimental features that have been introduced may confuse casual users. New features are frequently introduced, fiddled with, and judged to be found wanting, and then either discarded or totally rewritten. People reading the mailing list usually keep up with these rapid changes, whille people on the newsgroup can't be assumed to do so.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The new Gnus version couldn't have been done without the help of all the people on the (ding) mailing list. Every day for over a year I have gotten billions of nice bug reports from them, filling me with joy, every single one of them. Smooches. The people on the list have been tried beyond endurance, what with my "oh, that's a neat idea <type type>, yup, I'll release it right away <ship off> no wait, that doesn't work at all <type type>, yup, I'll ship that one off right away <ship off> no, wait, that absolutely does not work" policy for releases. Micro$oft--bah. Amateurs. I'm much worse. (Or is that "worser"? "much worser"? "worsest"?)
I would like to take this opportunity to thank the Academy for... oops, wrong show.
This manual was proof-read by Adrian Aichner, with Ricardo Nassif, Mark Borges, and Jost Krieger proof-reading parts of the manual.
The following people have contributed many patches and suggestions:
Christopher Davis, Andrew Eskilsson, Kai Grossjohann, David Kċgedal, Richard Pieri, Fabrice Popineau, Daniel Quinlan, Jason L. Tibbitts, III, and Jack Vinson.
Also thanks to the following for patches and stuff:
Jari Aalto, Adrian Aichner, Vladimir Alexiev, Russ Allbery, Peter Arius, Matt Armstrong, Marc Auslander, Miles Bader, Alexei V. Barantsev, Frank Bennett, Robert Bihlmeyer, Chris Bone, Mark Borges, Mark Boyns, Lance A. Brown, Rob Browning, Kees de Bruin, Martin Buchholz, Joe Buehler, Kevin Buhr, Alastair Burt, Joao Cachopo, Zlatko Calusic, Massimo Campostrini, Castor, David Charlap, Dan Christensen, Kevin Christian, Jae-you Chung, James H. Cloos, Jr., Laura Conrad, Michael R. Cook, Glenn Coombs, Andrew J. Cosgriff, Neil Crellin, Frank D. Cringle, Geoffrey T. Dairiki, Andre Deparade, Ulrik Dickow, Dave Disser, Rui-Tao Dong, Joev Dubach, Michael Welsh Duggan, Dave Edmondson, Paul Eggert, Mark W. Eichin, Karl Eichwalder, Enami Tsugutomo, Michael Ernst, Luc Van Eycken, Sam Falkner, Nelson Jose dos Santos Ferreira, Sigbjorn Finne, Sven Fischer, Paul Fisher, Decklin Foster, Gary D. Foster, Paul Franklin, Guy Geens, Arne Georg Gleditsch, David S. Goldberg, Michelangelo Grigni, Dale Hagglund, D. Hall, Magnus Hammerin, Kenichi Handa, Raja R. Harinath, Yoshiki Hayashi, P. E. Jareth Hein, Hisashige Kenji, Scott Hofmann, Marc Horowitz, Gunnar Horrigmo, Richard Hoskins, Brad Howes, Miguel de Icaza, François Felix Ingrand, Tatsuya Ichikawa, Ishikawa Ichiro, Lee Iverson, Iwamuro Motonori, Rajappa Iyer, Andreas Jaeger, Adam P. Jenkins, Randell Jesup, Fred Johansen, Gareth Jones, Simon Josefsson, Greg Klanderman, Karl Kleinpaste, Michael Klingbeil, Peter Skov Knudsen, Shuhei Kobayashi, Petr Konecny, Koseki Yoshinori, Thor Kristoffersen, Jens Lautenbacher, Martin Larose, Seokchan Lee, Joerg Lenneis, Carsten Leonhardt, James LewisMoss, Christian Limpach, Markus Linnala, Dave Love, Mike McEwan, Tonny Madsen, Shlomo Mahlab, Nat Makarevitch, Istvan Marko, David Martin, Jason R. Mastaler, Gordon Matzigkeit, Timo Metzemakers, Richard Mlynarik, Lantz Moore, Morioka Tomohiko, Erik Toubro Nielsen, Hrvoje Niksic, Andy Norman, Fred Oberhauser, C. R. Oldham, Alexandre Oliva, Ken Olstad, Masaharu Onishi, Hideki Ono, Ettore Perazzoli, William Perry, Stephen Peters, Jens-Ulrik Holger Petersen, Ulrich Pfeifer, Matt Pharr, Andy Piper, John McClary Prevost, Bill Pringlemeir, Mike Pullen, Jim Radford, Colin Rafferty, Lasse Rasinen, Lars Balker Rasmussen, Joe Reiss, Renaud Rioboo, Roland B. Roberts, Bart Robinson, Christian von Roques, Markus Rost, Jason Rumney, Wolfgang Rupprecht, Jay Sachs, Dewey M. Sasser, Conrad Sauerwald, Loren Schall, Dan Schmidt, Ralph Schleicher, Philippe Schnoebelen, Andreas Schwab, Randal L. Schwartz, Danny Siu, Matt Simmons, Paul D. Smith, Jeff Sparkes, Toby Speight, Michael Sperber, Darren Stalder, Richard Stallman, Greg Stark, Sam Steingold, Paul Stevenson, Jonas Steverud, Paul Stodghill, Kiyokazu Suto, Kurt Swanson, Samuel Tardieu, Teddy, Chuck Thompson, Tozawa Akihiko, Philippe Troin, James Troup, Trung Tran-Duc, Jack Twilley, Aaron M. Ucko, Aki Vehtari, Didier Verna, Vladimir Volovich, Jan Vroonhof, Stefan Waldherr, Pete Ware, Barry A. Warsaw, Christoph Wedler, Joe Wells, Lee Willis, Katsumi Yamaoka and Lloyd Zusman.
For a full overview of what each person has done, the ChangeLogs included in the Gnus alpha distributions should give ample reading (550kB and counting).
Apologies to everybody that I've forgotten, of which there are many, I'm sure.
Gee, that's quite a list of people. I guess that must mean that there actually are people who are using Gnus. Who'd'a thunk it!
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
10.1.9.1 (ding) Gnus New things in Gnus 5.0/5.1, the first new Gnus. 10.1.9.2 September Gnus The Thing Formally Known As Gnus 5.3/5.3. 10.1.9.3 Red Gnus Third time best--Gnus 5.4/5.5. 10.1.9.4 Quassia Gnus Two times two is four, or Gnus 5.6/5.7.
These lists are, of course, just short overviews of the most important new features. No, really. There are tons more. Yes, we have feeping creaturism in full effect.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
New features in Gnus 5.0/5.1:
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
New features in Gnus 5.2/5.3:
mail-mode
, rnews-reply-mode
and gnus-msg
are
now obsolete.
(setq gnus-build-sparse-threads 'some) |
trn
-like tree buffer can be displayed (see section 3.23 Tree Display).
(setq gnus-use-trees t) |
nn
-like pick-and-read minor mode is available for the summary
buffers (see section 3.22.1 Pick and Read).
(add-hook 'gnus-summary-mode-hook 'gnus-pick-mode) |
(add-hook 'gnus-group-mode-hook 'gnus-topic-mode) |
(add-hook 'gnus-summary-exit-hook 'gnus-summary-bubble-group) |
nndoc
now understands all kinds of digests, mail boxes, rnews
news batches, ClariNet briefs collections, and just about everything
else (see section 6.5.3 Document Groups).
nnsoup
) to create/read SOUP packets
(see section 6.5.4 SOUP).
Message-ID
.
gnus-buffer-configuration
(see section 8.5 Windows Configuration).
(setq gnus-use-nocem t) |
(setq gnus-permanently-visible-groups "^nnml:") |
Mail-Copies-To
header.
References
header
(see section 3.8.1 Customizing Threading).
(setq gnus-summary-thread-gathering-function 'gnus-gather-threads-by-references) |
(setq gnus-keep-backlog 50) |
(setq gnus-prompt-before-saving t) |
gnus-uu
can view decoded files asynchronously while fetching
articles (see section 3.15.5.2 Other Decode Variables).
(setq gnus-uu-grabbed-file-functions 'gnus-uu-grab-view) |
(setq gnus-cited-lines-visible 2) |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
New features in Gnus 5.4/5.5:
and
,
or
, not
, and parent redirection (see section 7.15 Advanced Scoring).
(setq gnus-suppress-duplicates t) |
nndoc
was rewritten to be easily extendable (see section 6.5.3.1 Document Server Internals).
nn
-like. Line
numbers are displayed and the . command can be used to pick
articles (Pick and Read
).
w
(see section 7.4 Score File Format).
(setq gnus-use-adaptive-scoring '(word)) |
(setq gnus-decay-scores t) |
nndoc
with nnvirtual
on top) has been added---M-C-d
(see section 3.25.4 Really Various Summary Commands).
Sorting
Groups
).
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
New features in Gnus 5.6:
nndraft
backend has returned, but works differently than
before. All Message buffers are now also articles in the nndraft
group, which is created automatically.
gnus-alter-header-function
can now be used to alter header
values.
gnus-summary-goto-article
now accept Message-ID's.
nnvirtual
groups with
C-u C-c C-c.
nntp-rlogin-program
---new variable to ease customization.
C-u C-c C-c
in gnus-article-edit-mode
will now inhibit
re-highlighting of the article buffer.
gnus-boring-article-headers
---long-to
.
gnus-simplify-subject-functions
variable to allow greater
control over simplification.
nnmail-split-methods
.
custom-face-lookup
function has been removed.
If you used this function in your initialization files, you must
rewrite them to use face-spec-set
instead.
nntp
, you can set
nntp-record-commands
to a non-nil
value.
nntp
now uses `~/.authinfo', a `.netrc'-like file, for
controlling where and how to send AUTHINFO to NNTP servers.
article-date-iso8601
.
gnus-score-thread-simplify
.
message-cite-original-without-signature
.
article-strip-all-blank-lines
---new article command.
gnus-adaptive-word-minimum
variable.
gnus-start-date-timer
command.
nnlistserv
backend.
nnweb
.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Also known as the todo list. Sure to be implemented before the next millennium.
Be afraid. Be very afraid.
(That a feature appears in this list doesn't necessarily mean that I've decided to actually implement it. It just means that I think it sounds interesting.)
(Yes, this is the actual, up-to-the-second todo list.)
Hypermail: <URL:http://www.falch.no/people/pepper/DSSSL-Lite/archives/> <URL:http://www.eit.com/software/hypermail/hypermail.html> <URL:http://homer.ncm.com/> <URL:http://www.yahoo.com/Computers_and_Internet/Internet/World_Wide_Web/HTML_Converters/> http://www.uwsg.indiana.edu/hypermail/linux/kernel/9610/index.html <URL:http://union.ncsa.uiuc.edu/HyperNews/get/www/html/converters.html> http://www.miranova.com/gnus-list/ |
push active file and NOV file parsing down into C code. `(canonize-message-id id)' `(mail-parent-message-id references n)' `(parse-news-nov-line &optional dependency-hashtb)' `(parse-news-nov-region beg end &optional dependency-hashtb fullp)' `(parse-news-active-region beg end hashtb)' |
From: John Griffith <griffith@sfs.nphil.uni-tuebingen.de>
In any case, there is a list of general news group archives at
ftp://ftp.neosoft.com/pub/users/claird/news.lists/newsgroup_archives.html
From: Jason L Tibbitts III <tibbs@hpc.uh.edu> (add-hook 'gnus-select-group-hook (lambda () (gnus-group-add-parameter group (cons 'gnus-group-date-last-entered (list (current-time-string)))))) (defun gnus-user-format-function-d (headers) "Return the date the group was last read." (cond ((car (gnus-group-get-parameter gnus-tmp-group 'gnus-group-date-last-entered))) (t ""))) |
It could also keep them updated (the same for the Status: header of unix mbox files).
They could be used like this:
`M l <name> RET' add label <name> to current message. `M u <name> RET' remove label <name> from current message. `/ l <expr> RET' limit summary buffer according to <expr>. <expr> would be a boolean expression on the labels, e.g. `/ l bug & !fixed RET' |
would show all the messages which are labeled `bug' but not labeled `fixed'.
One could also imagine the labels being used for highlighting, or affect the summary line format.
I'd like a gnus-find-file which work like find file, except that it would recognize things that looks like messages or folders:
- If it is a directory containing numbered files, create an nndir summary buffer.
- For other directories, create a nneething summary buffer.
- For files matching "\\`From ", create a nndoc/mbox summary.
- For files matching "\\`BABYL OPTIONS:", create a nndoc/baby summary.
- For files matching "\\`[^ \t\n]+:", create an *Article* buffer.
- For other files, just find them normally.
I'd like `nneething' to use this function, so it would work on a directory potentially containing mboxes or babyl files.
decend into sci? - type y decend into sci.something ? - type n decend into ucd?
The problem above is that since there is really only one subsection of science, shouldn't it prompt you for only descending sci.something? If there was a sci.somethingelse group or section, then it should prompt for sci? first the sci.something? then sci.somethingelse?...
^L's
more than n blank lines
more than m identical lines (which should be replaced with button to show them)
any whitespace surrounding any of the above
Group-mode show-list-of-articles-in-group if (key-pressed == SPACE) if (no-more-articles-in-group-to-select) if (articles-selected) start-reading-selected-articles; junk-unread-articles; next-group; else show-next-page; else if (key-pressed = '.') if (consolidated-menus) # same as hide-thread in Gnus select-thread-under-cursor; else select-article-under-cursor; Article-mode if (key-pressed == SPACE) if (more-pages-in-article) next-page; else if (more-selected-articles-to-read) next-article; else next-group; |
A more useful approach would be to, in response to the `G D' prompt, be allowed to say something like: `~/.mail/Incoming*', somewhat limiting the top-level directory only (in case directories would be matched by the wildcard expression).
<URL:news://sunsite.auc.dk/>
which should correspond to `B nntp RET sunsite.auc.dk' in *Group*.
Take a look at w3-menu.el in the Emacs-W3 distribution - this works out really well. Each menu is 'named' by a symbol that would be on a gnus-*-menus (where * would be whatever, but at least group, summary, and article versions) variable.
So for gnus-summary-menus, I would set to '(sort mark dispose ...)
A value of '1' would just put _all_ the menus in a single 'GNUS' menu in the main menubar. This approach works really well for Emacs-W3 and VM.
Add two commands:
* gnus-servers (gnus-start-server-buffer?)--enters Gnus and goes straight to the server buffer, without opening any connections to servers first.
* gnus-server-read-server-newsrc--produces a buffer very similar to the group buffer, but with only groups from that server listed; quitting this buffer returns to the server buffer.
(setq message-tab-alist '((message-header-regexp message-expand-group) ("^\\(To\\|[cC]c\\|[bB]cc\\)" bbdb-complete-name)))
then you could run the relevant function to complete the information in the header
(defun article-fix-m$word () "Fix M$Word smartquotes in an article." (interactive) (save-excursion (let ((buffer-read-only nil)) (goto-char (point-min)) (while (search-forward "\221" nil t) (replace-match "`" t t)) (goto-char (point-min)) (while (search-forward "\222" nil t) (replace-match "'" t t)) (goto-char (point-min)) (while (search-forward "\223" nil t) (replace-match "\"" t t)) (goto-char (point-min)) (while (search-forward "\224" nil t) (replace-match "\"" t t))))) |
(add-hook 'gnus-exit-query-functions '(lambda () (if (and (file-exists-p nnmail-spool-file) (> (nnheader-file-size nnmail-spool-file) 0)) (yes-or-no-p "New mail has arrived. Quit Gnus anyways? ") (y-or-n-p "Are you sure you want to quit Gnus? ")))) |
> > > If so, I've got one gripe: It seems that when I fire up gnus 5.2.25 > > > under xemacs-19.14, it's creating a new frame, but is erasing the > > > buffer in the frame that it was called from =:-O > > > Hm. How do you start up Gnus? From the toolbar or with > > `M-x gnus-other-frame'? > > I normally start it up from the toolbar; at > least that's the way I've caught it doing the > deed before. |
"\\(This\s+\\)?[^ ]+ has been automatically signed by" |
Is the "+" character illegal in newsgroup names? Is there any way in Gnus to work around this? (gnus 5.6.45 - XEmacs 20.4)
When `#F', do:
Subject: Answer to your mails 01.01.1999-01.05.1999 --text follows this line-- Sorry I killfiled you... Under the subject "foo", you wrote on 01.01.1999: > bar Under the subject "foo1", you wrote on 01.01.1999: > bar 1 |
- Edit article's summary line. - End edit - Sort lines in buffer by subject --> the old subject line appears in Summary buffer, not the one that was just changed to. |
(body "whatever.text") |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
I guess most manuals are written after-the-fact; documenting a program that's already there. This is not how this manual is written. When implementing something, I write the manual entry for that something straight away. I then see that it's difficult to explain the functionality, so I write how it's supposed to be, and then I change the implementation. Writing the documentation and writing the code goes hand in hand.
This, of course, means that this manual has no, or little, flow. It documents absolutely everything in Gnus, but often not where you're looking for it. It is a reference manual, and not a guide to how to get started with Gnus.
That would be a totally different book, that should be written using the reference manual as source material. It would look quite differently.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
gnus-build-sparse-threads
has been switched on.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
All variables are properly documented elsewhere in this manual. This section is designed to give general pointers on how to customize Gnus for some quite common situations.
10.4.1 Slow/Expensive NNTP Connection You run a local Emacs and get the news elsewhere. 10.4.2 Slow Terminal Connection You run a remote Emacs. 10.4.3 Little Disk Space You feel that having large setup files is icky. 10.4.4 Slow Machine You feel like buying a faster machine.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
If you run Emacs on a machine locally, and get your news from a machine over some very thin strings, you want to cut down on the amount of data Gnus has to get from the NNTP server.
gnus-read-active-file
nil
, which will inhibit Gnus from requesting the
entire active file from the server. This file is often v. large. You
also have to set gnus-check-new-newsgroups
and
gnus-check-bogus-newsgroups
to nil
to make sure that Gnus
doesn't suddenly decide to fetch the active file anyway.
gnus-nov-is-evil
nil
. If not, grabbing article headers from
the NNTP server will not be very fast. Not all NNTP servers
support XOVER; Gnus will detect this by itself.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Let's say you use your home computer for dialing up the system that runs Emacs and Gnus. If your modem is slow, you want to reduce (as much as possible) the amount of data sent over the wires.
gnus-auto-center-summary
nil
to inhibit Gnus from re-centering the summary
buffer all the time. If it is vertical
, do only vertical
re-centering. If it is neither nil
nor vertical
, do both
horizontal and vertical recentering.
gnus-visible-headers
Set this hook to all the available hiding commands:
(setq gnus-treat-hide-headers 'head gnus-treat-hide-signature t gnus-treat-hide-citation t) |
gnus-use-full-window
nil
, you can make all the windows smaller.
While this doesn't really cut down much generally, it means that you
have to see smaller portions of articles before deciding that you didn't
want to read them anyway.
gnus-thread-hide-subtree
nil
, all threads in the summary buffer will be
hidden initially.
gnus-updated-mode-lines
nil
, Gnus will not put information in the buffer mode
lines, which might save some time.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The startup files can get rather large, so you may want to cut their sizes a bit if you are running out of space.
gnus-save-newsrc-file
nil
, Gnus will never save `.newsrc'---it will
only save `.newsrc.eld'. This means that you will not be able to
use any other newsreaders than Gnus. This variable is t
by
default.
gnus-read-newsrc-file
nil
, Gnus will never read `.newsrc'---it will
only read `.newsrc.eld'. This means that you will not be able to
use any other newsreaders than Gnus. This variable is t
by
default.
gnus-save-killed-list
nil
, Gnus will not save the list of dead groups. You
should also set gnus-check-new-newsgroups
to ask-server
and gnus-check-bogus-newsgroups
to nil
if you set this
variable to nil
. This variable is t
by default.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
If you have a slow machine, or are just really impatient, there are a few things you can do to make Gnus run faster.
Set gnus-check-new-newsgroups
and
gnus-check-bogus-newsgroups
to nil
to make startup faster.
Set gnus-show-threads
, gnus-use-cross-reference
and
gnus-nov-is-evil
to nil
to make entering and exiting the
summary buffer faster.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Gnus works so well straight out of the box--I can't imagine any problems, really.
Ahem.
max-lisp-eval-depth
to 500 or
something like that.
If all else fails, report the problem as a bug.
If you find a bug in Gnus, you can report it with the M-x gnus-bug command. M-x set-variable RET debug-on-error RET t RET, and send me the backtrace. I will fix bugs, but I can only fix them if you send me a precise description as to how to reproduce the bug.
You really can never be too detailed in a bug report. Always use the M-x gnus-bug command when you make bug reports, even if it creates a 10Kb mail each time you use it, and even if you have sent me your environment 500 times before. I don't care. I want the full info each time.
It is also important to remember that I have no memory whatsoever. If you send a bug report, and I send you a reply, and then you just send back "No, it's not! Moron!", I will have no idea what you are insulting me about. Always over-explain everything. It's much easier for all of us--if I don't have all the information I need, I will just mail you and ask for more info, and everything takes more time.
If the problem you're seeing is very visual, and you can't quite explain
it, copy the Emacs window to a file (with xwd
, for instance), put
it somewhere it can be reached, and include the URL of the picture in
the bug report.
If you just need help, you are better off asking on `gnu.emacs.gnus'. I'm not very helpful.
You can also ask on the ding mailing list---`ding@gnus.org'. Write to `ding-request@gnus.org' to subscribe.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
It is my hope that other people will figure out smart stuff that Gnus can do, and that other people will write those smart things as well. To facilitate that I thought it would be a good idea to describe the inner workings of Gnus. And some of the not-so-inner workings, while I'm at it.
You can never expect the internals of a program not to change, but I will be defining (in some details) the interface between Gnus and its backends (this is written in stone), the format of the score files (ditto), data structures (some are less likely to change than others) and general methods of operation.
10.6.1 Gnus Utility Functions Common functions and variable to use. 10.6.2 Backend Interface How Gnus communicates with the servers. 10.6.3 Score File Syntax A BNF definition of the score file standard. 10.6.4 Headers How Gnus stores headers internally. 10.6.5 Ranges A handy format for storing mucho numbers. 10.6.6 Group Info The group info format. 10.6.7 Extended Interactive Symbolic prefixes and stuff. 10.6.8 Emacs/XEmacs Code Gnus can be run under all modern Emacsen. 10.6.9 Various File Formats Formats of files that Gnus use.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
When writing small functions to be run from hooks (and stuff), it's vital to have access to the Gnus internal functions and variables. Below is a list of the most common ones.
gnus-newsgroup-name
gnus-find-method-for-group
gnus-group-real-name
gnus-group-prefixed-name
gnus-get-info
gnus-group-unread
t
if that is
unknown.
gnus-active
gnus-set-active
gnus-add-current-to-buffer-list
gnus-continuum-version
gnus-group-read-only-p
gnus-news-group-p
gnus-ephemeral-group-p
gnus-server-to-method
gnus-server-equal
gnus-group-native-p
gnus-group-secondary-p
gnus-group-foreign-p
group-group-find-parameter
gnus-group-set-parameter
gnus-narrow-to-body
gnus-check-backend-function
nil
.
(gnus-check-backend-function "request-scan" "nnml:misc") => t |
gnus-read-method
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Gnus doesn't know anything about NNTP, spools, mail or virtual
groups. It only knows how to talk to virtual servers. A virtual
server is a backend and some backend variables. As examples
of the first, we have nntp
, nnspool
and nnmbox
. As
examples of the latter we have nntp-port-number
and
nnmbox-directory
.
When Gnus asks for information from a backend--say nntp
---on
something, it will normally include a virtual server name in the
function parameters. (If not, the backend should use the "current"
virtual server.) For instance, nntp-request-list
takes a virtual
server as its only (optional) parameter. If this virtual server hasn't
been opened, the function should fail.
Note that a virtual server name has no relation to some physical server name. Take this example:
(nntp "odd-one" (nntp-address "ifi.uio.no") (nntp-port-number 4324)) |
Here the virtual server name is `odd-one' while the name of the physical server is `ifi.uio.no'.
The backends should be able to switch between several virtual servers. The standard backends implement this by keeping an alist of virtual server environments that they pull down/push up when needed.
There are two groups of interface functions: required functions, which must be present, and optional functions, which Gnus will always check for presence before attempting to call 'em.
All these functions are expected to return data in the buffer
nntp-server-buffer
(` *nntpd*'), which is somewhat
unfortunately named, but we'll have to live with it. When I talk about
resulting data, I always refer to the data in that buffer. When I
talk about return value, I talk about the function value returned by
the function call. Functions that fail should return nil
as the
return value.
Some backends could be said to be server-forming backends, and some might be said not to be. The latter are backends that generally only operate on one group at a time, and have no concept of "server" -- they have a group, and they deliver info on that group and nothing more.
In the examples and definitions I will refer to the imaginary backend
nnchoke
.
10.6.2.1 Required Backend Functions Functions that must be implemented. 10.6.2.2 Optional Backend Functions Functions that need not be implemented. 10.6.2.3 Error Messaging How to get messages and report errors. 10.6.2.4 Writing New Backends Extending old backends. 10.6.2.5 Hooking New Backends Into Gnus What has to be done on the Gnus end. 10.6.2.6 Mail-like Backends Some tips on mail backends.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
(nnchoke-retrieve-headers ARTICLES &optional GROUP SERVER FETCH-OLD)
articles is either a range of article numbers or a list of
Message-ID
s. Current backends do not fully support either--only
sequences (lists) of article numbers, and most backends do not support
retrieval of Message-ID
s. But they should try for both.
The result data should either be HEADs or NOV lines, and the result
value should either be headers
or nov
to reflect this.
This might later be expanded to various
, which will be a mixture
of HEADs and NOV lines, but this is currently not supported by Gnus.
If fetch-old is non-nil
it says to try fetching "extra
headers", in some meaning of the word. This is generally done by
fetching (at most) fetch-old extra headers less than the smallest
article number in articles
, and filling the gaps as well. The
presence of this parameter can be ignored if the backend finds it
cumbersome to follow the request. If this is non-nil
and not a
number, do maximum fetches.
Here's an example HEAD:
221 1056 Article retrieved. Path: ifi.uio.no!sturles From: sturles@ifi.uio.no (Sturle Sunde) Newsgroups: ifi.discussion Subject: Re: Something very droll Date: 27 Oct 1994 14:02:57 +0100 Organization: Dept. of Informatics, University of Oslo, Norway Lines: 26 Message-ID: <38o8e1$a0o@holmenkollen.ifi.uio.no> References: <38jdmq$4qu@visbur.ifi.uio.no> NNTP-Posting-Host: holmenkollen.ifi.uio.no . |
So a headers
return value would imply that there's a number of
these in the data buffer.
Here's a BNF definition of such a buffer:
headers = *head head = error / valid-head error-message = [ "4" / "5" ] 2number " " <error message> eol valid-head = valid-message *header "." eol valid-message = "221 " |
If the return value is nov
, the data buffer should contain
network overview database lines. These are basically fields
separated by tabs.
nov-buffer = *nov-line nov-line = 8*9 [ field <TAB> ] eol field = <text except TAB> |
For a closer look at what should be in those fields, see section 10.6.4 Headers.
(nnchoke-open-server SERVER &optional DEFINITIONS)
server is here the virtual server name. definitions is a
list of (VARIABLE VALUE)
pairs that define this virtual server.
If the server can't be opened, no error should be signaled. The backend may then choose to refuse further attempts at connecting to this server. In fact, it should do so.
If the server is opened already, this function should return a
non-nil
value. There should be no data returned.
(nnchoke-close-server &optional SERVER)
Close connection to server and free all resources connected
to it. Return nil
if the server couldn't be closed for some
reason.
There should be no data returned.
(nnchoke-request-close)
Close connection to all servers and free all resources that the backend
have reserved. All buffers that have been created by that backend
should be killed. (Not the nntp-server-buffer
, though.) This
function is generally only called when Gnus is shutting down.
There should be no data returned.
(nnchoke-server-opened &optional SERVER)
If server is the current virtual server, and the connection to the
physical server is alive, then this function should return a
non-nil
vlue. This function should under no circumstances
attempt to reconnect to a server we have lost connection to.
There should be no data returned.
(nnchoke-status-message &optional SERVER)
This function should return the last error message from server.
There should be no data returned.
(nnchoke-request-article ARTICLE &optional GROUP SERVER TO-BUFFER)
The result data from this function should be the article specified by
article. This might either be a Message-ID
or a number.
It is optional whether to implement retrieval by Message-ID
, but
it would be nice if that were possible.
If to-buffer is non-nil
, the result data should be returned
in this buffer instead of the normal data buffer. This is to make it
possible to avoid copying large amounts of data from one buffer to
another, while Gnus mainly requests articles to be inserted directly
into its article buffer.
If it is at all possible, this function should return a cons cell where
the car
is the group name the article was fetched from, and the cdr
is
the article number. This will enable Gnus to find out what the real
group and article numbers are when fetching articles by
Message-ID
. If this isn't possible, t
should be returned
on successful article retrieval.
(nnchoke-request-group GROUP &optional SERVER FAST)
Get data on group. This function also has the side effect of making group the current group.
If fast, don't bother to return useful data, just make group the current group.
Here's an example of some result data and a definition of the same:
211 56 1000 1059 ifi.discussion |
The first number is the status, which should be 211. Next is the total number of articles in the group, the lowest article number, the highest article number, and finally the group name. Note that the total number of articles may be less than one might think while just considering the highest and lowest article numbers, but some articles may have been canceled. Gnus just discards the total-number, so whether one should take the bother to generate it properly (if that is a problem) is left as an exercise to the reader.
group-status = [ error / info ] eol error = [ "4" / "5" ] 2 |
(nnchoke-close-group GROUP &optional SERVER)
Close group and free any resources connected to it. This will be a no-op on most backends.
There should be no data returned.
(nnchoke-request-list &optional SERVER)
Return a list of all groups available on server. And that means all.
Here's an example from a server that only carries two groups:
ifi.test 0000002200 0000002000 y ifi.discussion 3324 3300 n |
On each line we have a group name, then the highest article number in that group, the lowest article number, and finally a flag.
active-file = *active-line active-line = name " " |
The flag says whether the group is read-only (`n'), is moderated (`m'), is dead (`x'), is aliased to some other group (`=other-group') or none of the above (`y').
(nnchoke-request-post &optional SERVER)
This function should post the current buffer. It might return whether the posting was successful or not, but that's not required. If, for instance, the posting is done asynchronously, it has generally not been completed by the time this function concludes. In that case, this function should set up some kind of sentinel to beep the user loud and clear if the posting could not be completed.
There should be no result data from this function.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
(nnchoke-retrieve-groups GROUPS &optional SERVER)
groups is a list of groups, and this function should request data on all those groups. How it does it is of no concern to Gnus, but it should attempt to do this in a speedy fashion.
The return value of this function can be either active
or
group
, which says what the format of the result data is. The
former is in the same format as the data from
nnchoke-request-list
, while the latter is a buffer full of lines
in the same format as nnchoke-request-group
gives.
group-buffer = *active-line / *group-status |
(nnchoke-request-update-info GROUP INFO &optional SERVER)
A Gnus group info (see section 10.6.6 Group Info) is handed to the backend for alterations. This comes in handy if the backend really carries all the information (as is the case with virtual and imap groups). This function should destructively alter the info to suit its needs, and should return the (altered) group info.
There should be no result data from this function.
(nnchoke-request-type GROUP &optional ARTICLE)
When the user issues commands for "sending news" (F in the
summary buffer, for instance), Gnus has to know whether the article the
user is following up on is news or mail. This function should return
news
if article in group is news, mail
if it
is mail and unknown
if the type can't be decided. (The
article parameter is necessary in nnvirtual
groups which
might very well combine mail groups and news groups.) Both group
and article may be nil
.
There should be no result data from this function.
(nnchoke-request-set-mark GROUP ACTION &optional SERVER)
Set/remove/add marks on articles. Normally Gnus handles the article
marks (such as read, ticked, expired etc) internally, and store them in
~/.newsrc.eld
. Some backends (such as IMAP) however carry
all information about the articles on the server, so Gnus need to
propagate the mark information to the server.
ACTION is a list of mark setting requests, having this format:
(RANGE ACTION MARK) |
Range is a range of articles you wish to update marks on. Action is
set
, add
or del
, respectively used for removing all
existing marks and setting them as specified, adding (preserving the
marks not mentioned) mark and removing (preserving the marks not
mentioned) marks. Mark is a list of marks; where each mark is a symbol.
Currently used marks are read
, tick
, reply
,
expire
, killed
, dormant
, save
,
download
and unsend
, but your backend should, if possible,
not limit itself to these.
Given contradictory actions, the last action in the list should be the
effective one. That is, if your action contains a request to add the
tick
mark on article 1 and, later in the list, a request to
remove the mark on the same article, the mark should in fact be removed.
An example action list:
(((5 12 30) 'del '(tick)) ((10 . 90) 'add '(read expire)) ((92 94) 'del '(read))) |
The function should return a range of articles it wasn't able to set the mark on (currently not used for anything).
There should be no result data from this function.
(nnchoke-request-update-mark GROUP ARTICLE MARK)
If the user tries to set a mark that the backend doesn't like, this
function may change the mark. Gnus will use whatever this function
returns as the mark for article instead of the original
mark. If the backend doesn't care, it must return the original
mark, and not nil
or any other type of garbage.
The only use for this I can see is what nnvirtual
does with
it--if a component group is auto-expirable, marking an article as read
in the virtual group should result in the article being marked as
expirable.
There should be no result data from this function.
(nnchoke-request-scan &optional GROUP SERVER)
This function may be called at any time (by Gnus or anything else) to request that the backend check for incoming articles, in one way or another. A mail backend will typically read the spool file or query the POP server when this function is invoked. The group doesn't have to be heeded--if the backend decides that it is too much work just scanning for a single group, it may do a total scan of all groups. It would be nice, however, to keep things local if that's practical.
There should be no result data from this function.
(nnchoke-request-group-description GROUP &optional SERVER)
The result data from this function should be a description of group.
description-line = name <TAB> description eol name = <string> description = <text> |
(nnchoke-request-list-newsgroups &optional SERVER)
The result data from this function should be the description of all groups available on the server.
description-buffer = *description-line |
(nnchoke-request-newgroups DATE &optional SERVER)
The result data from this function should be all groups that were created after `date', which is in normal human-readable date format. The data should be in the active buffer format.
(nnchoke-request-create-group GROUP &optional SERVER)
This function should create an empty group with name group.
There should be no return data.
(nnchoke-request-expire-articles ARTICLES &optional GROUP SERVER FORCE)
This function should run the expiry process on all articles in the
articles range (which is currently a simple list of article
numbers.) It is left up to the backend to decide how old articles
should be before they are removed by this function. If force is
non-nil
, all articles should be deleted, no matter how new
they are.
This function should return a list of articles that it did not/was not able to delete.
There should be no result data returned.
(nnchoke-request-move-article ARTICLE GROUP SERVER ACCEPT-FORM
This function should move article (which is a number) from group by calling accept-form.
This function should ready the article in question for moving by
removing any header lines it has added to the article, and generally
should "tidy up" the article. Then it should eval
accept-form in the buffer where the "tidy" article is. This
will do the actual copying. If this eval
returns a
non-nil
value, the article should be removed.
If last is nil
, that means that there is a high likelihood
that there will be more requests issued shortly, so that allows some
optimizations.
The function should return a cons where the car
is the group name and
the cdr
is the article number that the article was entered as.
There should be no data returned.
(nnchoke-request-accept-article GROUP &optional SERVER LAST)
This function takes the current buffer and inserts it into group.
If last in nil
, that means that there will be more calls to
this function in short order.
The function should return a cons where the car
is the group name and
the cdr
is the article number that the article was entered as.
There should be no data returned.
(nnchoke-request-replace-article ARTICLE GROUP BUFFER)
This function should remove article (which is a number) from group and insert buffer there instead.
There should be no data returned.
(nnchoke-request-delete-group GROUP FORCE &optional SERVER)
This function should delete group. If force, it should really delete all the articles in the group, and then delete the group itself. (If there is such a thing as "the group itself".)
There should be no data returned.
(nnchoke-request-rename-group GROUP NEW-NAME &optional SERVER)
This function should rename group into new-name. All articles in group should move to new-name.
There should be no data returned.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The backends should use the function nnheader-report
to report
error conditions--they should not raise errors when they aren't able to
perform a request. The first argument to this function is the backend
symbol, and the rest are interpreted as arguments to format
if
there are multiple of them, or just a string if there is one of them.
This function must always returns nil
.
(nnheader-report 'nnchoke "You did something totally bogus") (nnheader-report 'nnchoke "Could not request group %s" group) |
Gnus, in turn, will call nnheader-get-report
when it gets a
nil
back from a server, and this function returns the most
recently reported message for the backend in question. This function
takes one argument--the server symbol.
Internally, these functions access backend-status-string
,
so the nnchoke
backend will have its error message stored in
nnchoke-status-string
.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Many backends are quite similar. nnml
is just like
nnspool
, but it allows you to edit the articles on the server.
nnmh
is just like nnml
, but it doesn't use an active file,
and it doesn't maintain overview databases. nndir
is just like
nnml
, but it has no concept of "groups", and it doesn't allow
editing articles.
It would make sense if it were possible to "inherit" functions from backends when writing new backends. And, indeed, you can do that if you want to. (You don't have to if you don't want to, of course.)
All the backends declare their public variables and functions by using a
package called nnoo
.
To inherit functions from other backends (and allow other backends to inherit functions from the current backend), you should use the following macros:
nnoo-declare
(nnoo-declare nndir nnml nnmh) |
nndir
has declared here that it intends to inherit functions from
both nnml
and nnmh
.
defvoo
defvar
, but registers the variable as
a public server variable. Most state-oriented variables should be
declared with defvoo
instead of defvar
.
In addition to the normal defvar
parameters, it takes a list of
variables in the parent backends to map the variable to when executing
a function in those backends.
(defvoo nndir-directory nil "Where nndir will look for groups." nnml-current-directory nnmh-current-directory) |
This means that nnml-current-directory
will be set to
nndir-directory
when an nnml
function is called on behalf
of nndir
. (The same with nnmh
.)
nnoo-define-basics
(nnoo-define-basics nndir) |
deffoo
defun
and takes the same parameters. In
addition to doing the normal defun
things, it registers the
function as being public so that other backends can inherit it.
nnoo-map-functions
(nnoo-map-functions nndir (nnml-retrieve-headers 0 nndir-current-group 0 0) (nnmh-request-article 0 nndir-current-group 0 0)) |
This means that when nndir-retrieve-headers
is called, the first,
third, and fourth parameters will be passed on to
nnml-retrieve-headers
, while the second parameter is set to the
value of nndir-current-group
.
nnoo-import
(nnoo-import nndir (nnmh nnmh-request-list nnmh-request-newgroups) (nnml)) |
This means that calls to nndir-request-list
should just be passed
on to nnmh-request-list
, while all public functions from
nnml
that haven't been defined in nndir
yet should be
defined now.
Below is a slightly shortened version of the nndir
backend.
;;; nndir.el --- single directory newsgroup access for Gnus ;; Copyright (C) 1995,96 Free Software Foundation, Inc. ;;; Code: (require 'nnheader) (require 'nnmh) (require 'nnml) (require 'nnoo) (eval-when-compile (require 'cl)) (nnoo-declare nndir nnml nnmh) (defvoo nndir-directory nil "Where nndir will look for groups." nnml-current-directory nnmh-current-directory) (defvoo nndir-nov-is-evil nil "*Non-nil means that nndir will never retrieve NOV headers." nnml-nov-is-evil) (defvoo nndir-current-group "" nil nnml-current-group nnmh-current-group) (defvoo nndir-top-directory nil nil nnml-directory nnmh-directory) (defvoo nndir-get-new-mail nil nil nnml-get-new-mail nnmh-get-new-mail) (defvoo nndir-status-string "" nil nnmh-status-string) (defconst nndir-version "nndir 1.0") ;;; Interface functions. (nnoo-define-basics nndir) (deffoo nndir-open-server (server &optional defs) (setq nndir-directory (or (cadr (assq 'nndir-directory defs)) server)) (unless (assq 'nndir-directory defs) (push `(nndir-directory ,server) defs)) (push `(nndir-current-group ,(file-name-nondirectory (directory-file-name nndir-directory))) defs) (push `(nndir-top-directory ,(file-name-directory (directory-file-name nndir-directory))) defs) (nnoo-change-server 'nndir server defs)) (nnoo-map-functions nndir (nnml-retrieve-headers 0 nndir-current-group 0 0) (nnmh-request-article 0 nndir-current-group 0 0) (nnmh-request-group nndir-current-group 0 0) (nnmh-close-group nndir-current-group 0)) (nnoo-import nndir (nnmh nnmh-status-message nnmh-request-list nnmh-request-newgroups)) (provide 'nndir) |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Having Gnus start using your new backend is rather easy--you just
declare it with the gnus-declare-backend
functions. This will
enter the backend into the gnus-valid-select-methods
variable.
gnus-declare-backend
takes two parameters--the backend name and
an arbitrary number of abilities.
Here's an example:
(gnus-declare-backend "nnchoke" 'mail 'respool 'address) |
The abilities can be:
mail
post
post-mail
none
respool
address
prompt-address
nntp
, but not nnmbox
, for instance.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
One of the things that separate the mail backends from the rest of the
backends is the heavy dependence by the mail backends on common
functions in `nnmail.el'. For instance, here's the definition of
nnml-request-scan
:
(deffoo nnml-request-scan (&optional group server) (setq nnml-article-file-alist nil) (nnmail-get-new-mail 'nnml 'nnml-save-nov nnml-directory group)) |
It simply calls nnmail-get-new-mail
with a few parameters,
and nnmail
takes care of all the moving and splitting of the
mail.
This function takes four parameters.
nnmail-get-new-mail
will call backend-save-mail
to
save each article. backend-active-number
will be called to
find the article number assigned to this article.
The function also uses the following variables:
backend-get-new-mail
(to see whether to get new mail for
this backend); and backend-group-alist
and
backend-active-file
to generate the new active file.
backend-group-alist
should be a group-active alist, like
this:
(("a-group" (1 . 10)) ("some-group" (34 . 39))) |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Score files are meant to be easily parseable, but yet extremely mallable. It was decided that something that had the same read syntax as an Emacs Lisp list would fit that spec.
Here's a typical score file:
(("summary" ("win95" -10000 nil s) ("Gnus")) ("from" ("Lars" -1000)) (mark -100)) |
BNF definition of a score file:
score-file = "" / "(" *element ")" element = rule / atom rule = string-rule / number-rule / date-rule string-rule = "(" quote string-header quote space *string-match ")" number-rule = "(" quote number-header quote space *number-match ")" date-rule = "(" quote date-header quote space *date-match ")" quote = <ascii 34> string-header = "subject" / "from" / "references" / "message-id" / "xref" / "body" / "head" / "all" / "followup" number-header = "lines" / "chars" date-header = "date" string-match = "(" quote |
Any unrecognized elements in a score file should be ignored, but not discarded.
As you can see, white space is needed, but the type and amount of white space is irrelevant. This means that formatting of the score file is left up to the programmer--if it's simpler to just spew it all out on one looong line, then that's ok.
The meaning of the various atoms are explained elsewhere in this manual (see section 7.4 Score File Format).
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Internally Gnus uses a format for storing article headers that corresponds to the NOV format in a mysterious fashion. One could almost suspect that the author looked at the NOV specification and just shamelessly stole the entire thing, and one would be right.
Header is a severely overloaded term. "Header" is used in
RFC 1036 to talk about lines in the head of an article (e.g.,
From
). It is used by many people as a synonym for
"head"---"the header and the body". (That should be avoided, in my
opinion.) And Gnus uses a format internally that it calls "header",
which is what I'm talking about here. This is a 9-element vector,
basically, with each header (ouch) having one slot.
These slots are, in order: number
, subject
, from
,
date
, id
, references
, chars
, lines
,
xref
, and extra
. There are macros for accessing and
setting these slots--they all have predictable names beginning with
mail-header-
and mail-header-set-
, respectively.
All these slots contain strings, except the extra
slot, which
contains an alist of header/value pairs (see section 3.1.2 To From Newsgroups).
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
GNUS introduced a concept that I found so useful that I've started using it a lot and have elaborated on it greatly.
The question is simple: If you have a large amount of objects that are identified by numbers (say, articles, to take a wild example) that you want to qualify as being "included", a normal sequence isn't very useful. (A 200,000 length sequence is a bit long-winded.)
The solution is as simple as the question: You just collapse the sequence.
(1 2 3 4 5 6 10 11 12) |
is transformed into
((1 . 6) (10 . 12)) |
To avoid having those nasty `(13 . 13)' elements to denote a lonesome object, a `13' is a valid element:
((1 . 6) 7 (10 . 12)) |
This means that comparing two ranges to find out whether they are equal is slightly tricky:
((1 . 5) 7 8 (10 . 12)) |
and
((1 . 5) (7 . 8) (10 . 12)) |
are equal. In fact, any non-descending list is a range:
(1 2 3 4 5) |
is a perfectly valid range, although a pretty long-winded one. This is also valid:
(1 . 5) |
and is equal to the previous range.
Here's a BNF definition of ranges. Of course, one must remember the semantic requirement that the numbers are non-descending. (Any number of repetition of the same number is allowed, but apt to disappear in range handling.)
range = simple-range / normal-range simple-range = "(" number " . " number ")" normal-range = "(" start-contents ")" contents = "" / simple-range *[ " " contents ] / number *[ " " contents ] |
Gnus currently uses ranges to keep track of read articles and article marks. I plan on implementing a number of range operators in C if The Powers That Be are willing to let me. (I haven't asked yet, because I need to do some more thinking on what operators I need to make life totally range-based without ever having to convert back to normal sequences.)
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Gnus stores all permanent info on groups in a group info list. This list is from three to six elements (or more) long and exhaustively describes the group.
Here are two example group infos; one is a very simple group while the second is a more complex one:
("no.group" 5 ((1 . 54324))) ("nnml:my.mail" 3 ((1 . 5) 9 (20 . 55)) ((tick (15 . 19)) (replied 3 6 (19 . 3))) (nnml "") ((auto-expire . t) (to-address . "ding@gnus.org"))) |
The first element is the group name---as Gnus knows the group,
anyway. The second element is the subscription level, which
normally is a small integer. (It can also be the rank, which is a
cons cell where the car
is the level and the cdr
is the
score.) The third element is a list of ranges of read articles. The
fourth element is a list of lists of article marks of various kinds.
The fifth element is the select method (or virtual server, if you like).
The sixth element is a list of group parameters, which is what
this section is about.
Any of the last three elements may be missing if they are not required. In fact, the vast majority of groups will normally only have the first three elements, which saves quite a lot of cons cells.
Here's a BNF definition of the group info format:
info = "(" group space ralevel space read [ "" / [ space marks-list [ "" / [ space method [ "" / space parameters ] ] ] ] ] ")" group = quote <string> quote ralevel = rank / level level = <integer in the range of 1 to inf> rank = "(" level "." score ")" score = <integer in the range of 1 to inf> read = range marks-lists = nil / "(" *marks ")" marks = "(" |
Actually that `marks' rule is a fib. A `marks' is a `<string>' consed on to a `range', but that's a bitch to say in pseudo-BNF.
If you have a Gnus info and want to access the elements, Gnus offers a series of macros for getting/setting these elements.
gnus-info-group
gnus-info-set-group
gnus-info-rank
gnus-info-set-rank
gnus-info-level
gnus-info-set-level
gnus-info-score
gnus-info-set-score
gnus-info-read
gnus-info-set-read
gnus-info-marks
gnus-info-set-marks
gnus-info-method
gnus-info-set-method
gnus-info-params
gnus-info-set-params
All the getter functions take one parameter--the info list. The setter functions take two parameters--the info list and the new value.
The last three elements in the group info aren't mandatory, so it may be
necessary to extend the group info before setting the element. If this
is necessary, you can just pass on a non-nil
third parameter to
the three final setter functions to have this happen automatically.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Gnus extends the standard Emacs interactive
specification
slightly to allow easy use of the symbolic prefix (see section 8.3 Symbolic Prefixes). Here's an example of how this is used:
(defun gnus-summary-increase-score (&optional score symp) (interactive (gnus-interactive "P\ny")) ... ) |
The best thing to do would have been to implement
gnus-interactive
as a macro which would have returned an
interactive
form, but this isn't possible since Emacs checks
whether a function is interactive or not by simply doing an assq
on the lambda form. So, instead we have gnus-interactive
function that takes a string and returns values that are usable to
interactive
.
This function accepts (almost) all normal interactive
specs, but
adds a few more.
gnus-current-prefix-symbol
variable.
gnus-current-prefix-symbol
variable.
gnus-summary-article-number
function.
gnus-summary-article-header
function.
gnus-group-group-name
function.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
While Gnus runs under Emacs, XEmacs and Mule, I decided that one of the platforms must be the primary one. I chose Emacs. Not because I don't like XEmacs or Mule, but because it comes first alphabetically.
This means that Gnus will byte-compile under Emacs with nary a warning, while XEmacs will pump out gigabytes of warnings while byte-compiling. As I use byte-compilation warnings to help me root out trivial errors in Gnus, that's very useful.
I've also consistently used Emacs function interfaces, but have used
Gnusey aliases for the functions. To take an example: Emacs defines a
run-at-time
function while XEmacs defines a start-itimer
function. I then define a function called gnus-run-at-time
that
takes the same parameters as the Emacs run-at-time
. When running
Gnus under Emacs, the former function is just an alias for the latter.
However, when running under XEmacs, the former is an alias for the
following function:
(defun gnus-xmas-run-at-time (time repeat function &rest args) (start-itimer "gnus-run-at-time" `(lambda () (,function ,@args)) time repeat)) |
This sort of thing has been done for bunches of functions. Gnus does
not redefine any native Emacs functions while running under XEmacs--it
does this defalias
thing with Gnus equivalents instead. Cleaner
all over.
In the cases where the XEmacs function interface was obviously cleaner,
I used it instead. For example gnus-region-active-p
is an alias
for region-active-p
in XEmacs, whereas in Emacs it is a function.
Of course, I could have chosen XEmacs as my native platform and done mapping functions the other way around. But I didn't. The performance hit these indirections impose on Gnus under XEmacs should be slight.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
10.6.9.1 Active File Format Information on articles and groups available. 10.6.9.2 Newsgroups File Format Group descriptions.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The active file lists all groups available on the server in question. It also lists the highest and lowest current article numbers in each group.
Here's an excerpt from a typical active file:
soc.motss 296030 293865 y alt.binaries.pictures.fractals 3922 3913 n comp.sources.unix 1605 1593 m comp.binaries.ibm.pc 5097 5089 y no.general 1000 900 y |
Here's a pseudo-BNF definition of this file:
active = *group-line group-line = group space high-number space low-number space flag <NEWLINE> group = <non-white-space string> space = " " high-number = <non-negative integer> low-number = <positive integer> flag = "y" / "n" / "m" / "j" / "x" / "=" group |
For a full description of this file, see the manual pages for `innd', in particular `active(5)'.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The newsgroups file lists groups along with their descriptions. Not all groups on the server have to be listed, and not all groups in the file have to exist on the server. The file is meant purely as information to the user.
The format is quite simple; a group name, a tab, and the description. Here's the definition:
newsgroups = *line line = group tab description <NEWLINE> group = <non-white-space string> tab = <TAB> description = <string> |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Believe it or not, but some people who use Gnus haven't really used
Emacs much before they embarked on their journey on the Gnus Love Boat.
If you are one of those unfortunates whom "M-C-a", "kill the
region", and "set gnus-flargblossen
to an alist where the key
is a regexp that is used for matching on the group name" are magical
phrases with little or no meaning, then this appendix is for you. If
you are already familiar with Emacs, just ignore this and go fondle your
cat instead.
10.7.1 Keystrokes Entering text and executing commands. 10.7.2 Emacs Lisp The built-in Emacs programming language.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Yes, when you use Emacs, you are apt to use the control key, the shift
key and the meta key a lot. This is very annoying to some people
(notably vi
le users), and the rest of us just love the hell out
of it. Just give up and submit. Emacs really does stand for
"Escape-Meta-Alt-Control-Shift", and not "Editing Macros", as you
may have heard from other disreputable sources (like the Emacs author).
The shift keys are normally located near your pinky fingers, and are normally used to get capital letters and stuff. You probably use it all the time. The control key is normally marked "CTRL" or something like that. The meta key is, funnily enough, never marked as such on any keyboard. The one I'm currently at has a key that's marked "Alt", which is the meta key on this keyboard. It's usually located somewhere to the left hand side of the keyboard, usually on the bottom row.
Now, us Emacs people don't say "press the meta-control-m key", because that's just too inconvenient. We say "press the M-C-m key". M- is the prefix that means "meta" and "C-" is the prefix that means "control". So "press C-k" means "press down the control key, and hold it down while you press k". "Press M-C-k" means "press down and hold down the meta key and the control key and then press k". Simple, ay?
This is somewhat complicated by the fact that not all keyboards have a meta key. In that case you can use the "escape" key. Then M-k means "press escape, release escape, press k". That's much more work than if you have a meta key, so if that's the case, I respectfully suggest you get a real keyboard with a meta key. You can't live without it.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Emacs is the King of Editors because it's really a Lisp interpreter. Each and every key you tap runs some Emacs Lisp code snippet, and since Emacs Lisp is an interpreted language, that means that you can configure any key to run any arbitrary code. You just, like, do it.
Gnus is written in Emacs Lisp, and is run as a bunch of interpreted functions. (These are byte-compiled for speed, but it's still interpreted.) If you decide that you don't like the way Gnus does certain things, it's trivial to have it do something a different way. (Well, at least if you know how to write Lisp code.) However, that's beyond the scope of this manual, so we are simply going to talk about some common constructs that you normally use in your `.emacs' file to customize Gnus.
If you want to set the variable gnus-florgbnize
to four (4), you
write the following:
(setq gnus-florgbnize 4) |
This function (really "special form") setq
is the one that can
set a variable to some value. This is really all you need to know. Now
you can go and fill your .emacs
file with lots of these to change
how Gnus works.
If you have put that thing in your .emacs
file, it will be read
and eval
ed (which is lisp-ese for "run") the next time you
start Emacs. If you want to change the variable right away, simply say
C-x C-e after the closing parenthesis. That will eval
the
previous "form", which is a simple setq
statement here.
Go ahead--just try it, if you're located at your Emacs. After you
C-x C-e, you will see `4' appear in the echo area, which
is the return value of the form you eval
ed.
Some pitfalls:
If the manual says "set gnus-read-active-file
to some
",
that means:
(setq gnus-read-active-file 'some) |
On the other hand, if the manual says "set gnus-nntp-server
to
`nntp.ifi.uio.no'", that means:
(setq gnus-nntp-server "nntp.ifi.uio.no") |
So be careful not to mix up strings (the latter) with symbols (the former). The manual is unambiguous, but it can be confusing.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This is the Gnus Frequently Asked Questions list. If you have a Web browser, the official hypertext version is at `http://www.ccs.neu.edu/software/gnus/', and has probably been updated since you got this manual.
10.8.1 Installation Installation of Gnus. 10.8.2 Customization Customizing Gnus. 10.8.3 Reading News News Reading Questions. 10.8.4 Reading Mail Mail Reading Questions.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The latest (and greatest) version is 5.0.10. You might also run across something called September Gnus. September Gnus is the alpha version of the next major release of Gnus. It is currently not stable enough to run unless you are prepared to debug lisp.
Any of the following locations:
At least GNU Emacs 19.28, or XEmacs 19.12 is recommended. GNU Emacs 19.25 has been reported to work under certain circumstances, but it doesn't officially work on it. 19.27 has also been reported to work. Gnus has been reported to work under OS/2 as well as Unix.
Upgrade to XEmacs 19.13. In earlier versions of XEmacs this file was placed with Gnus 4.1.3, but that has been corrected.
You're running an old version of Gnus. Upgrade to at least version 5.0.4.
Send an e-mail message to `ding-request@ifi.uio.no' with the magic word unsubscribe somewhere in it, and you will be removed.
If you are reading the digest version of the list, send an e-mail message
to
`ding-rn-digests-d-request@moe.shore.net'
with unsubscribe as the subject and you will be removed.
The basic answer is to byte-compile under XEmacs, and then you can run under either Emacsen. There is, however, a potential version problem with easymenu.el with Gnu Emacs prior to 19.29.
Per Abrahamsen <abraham@dina.kvl.dk> writes :
The internal easymenu.el interface changed between 19.28 and 19.29 in
order to make it possible to create byte compiled files that can be
shared between Gnu Emacs and XEmacs. The change is upward
compatible, but not downward compatible.
This gives the following compatibility table:
Compiled with: | Can be used with: ----------------+-------------------------------------- 19.28 | 19.28 19.29 19.29 | 19.29 XEmacs XEmacs | 19.29 XEmacs |
If you have Gnu Emacs 19.28 or earlier, or XEmacs 19.12 or earlier, get a recent version of auc-menu.el from `ftp://ftp.iesd.auc.dk/pub/emacs-lisp/auc-menu.el', and install it under the name easymenu.el somewhere early in your load path.
There is the newsgroup Gnu.emacs.gnus. Discussion of Gnus 5.x is now taking place there. There is also a mailing list, send mail to `ding-request@ifi.uio.no' with the magic word subscribe somewhere in it.
NOTE: the traffic on this list is heavy so you may not want to be on it (unless you use Gnus as your mailer reader, that is). The mailing list is mainly for developers and testers.
Gnus has a home World Wide Web page at
`http://www.ifi.uio.no/~larsi/ding.html'.
Gnus has a write up in the X Windows Applications FAQ at
`http://www.ee.ryerson.ca:8080/~elf/xapps/Q-III.html'.
The Gnus manual is also available on the World Wide Web. The canonical
source is in Norway at
`http://www.ifi.uio.no/~larsi/ding-manual/gnus_toc.html'.
There are three mirrors in the United States:
PostScript copies of the Gnus Reference card are available from
`ftp://ftp.cs.ualberta.ca/pub/oolog/gnus/'. They are mirrored at
`ftp://ftp.pilgrim.umass.edu/pub/misc/ding/refcard/' in the
United States. And
`ftp://marvin.fkphy.uni-duesseldorf.de/pub/gnus/'
in Germany.
An online version of the Gnus FAQ is available at
`http://www.miranova.com/~steve/gnus-faq.html'. Off-line formats
are also available:
ASCII: `ftp://ftp.miranova.com/pub/gnus/gnus-faq'
PostScript: `ftp://ftp.miranova.com/pub/gnus/gnus-faq.ps'.
I am running XEmacs on SunOS and Gnus prints a message about Connecting to NNTP server and then just hangs.
Ben Wing <wing@netcom.com> writes :
I wonder if you're hitting the infamous libresolv problem.
The basic problem is that under SunOS you can compile either
with DNS or NIS name lookup libraries but not both. Try
substituting the IP address and see if that works; if so, you
need to download the sources and recompile.
This problem is verified to still exist in Gnus 5.0.9 and Mailcrypt 3.4. The answer comes from Peter Arius <arius@immd2.informatik.uni-erlangen.de>.
I found out that mailcrypt uses
gnus-eval-in-buffer-window
, which is a macro.
It seems as if you have
compiled mailcrypt with plain old GNUS in load path, and the XEmacs byte
compiler has inserted that macro definition into
`mc-toplev.elc'.
The solution is to recompile `mc-toplev.el' with Gnus 5 in
load-path, and it works fine.
Steve Baur <steve@miranova.com> adds :
The problem also manifests itself if neither GNUS 4 nor Gnus 5 is in the
load-path.
Mailcrypt is an Emacs interface to PGP. It works, it installs
without hassle, and integrates very easily. Mailcrypt can be
obtained from
`ftp://cag.lcs.mit.edu/pub/patl/mailcrypt-3.4.tar.gz'.
Tools for Mime is an Emacs MUA interface to MIME. Installation is
a two-step process unlike most other packages, so you should
be prepared to move the byte-compiled code somewhere. There
are currently two versions of this package available. It can
be obtained from
`ftp://ftp.jaist.ac.jp/pub/GNU/elisp/'.
Be sure to apply the supplied patch. It works with Gnus through
version 5.0.9. In order for all dependencies to work correctly
the load sequence is as follows:
(load "tm-setup") (load "gnus") (load "mime-compose") |
NOTE: Loading the package disables citation highlighting by default. To get the old behavior back, use the M-t command.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The custom package has not been ported to XEmacs.
I see lots of messages with quoted material in them. I am wondering how to have Gnus do it for me.
This is Gnus, so there are a number of ways of doing this. You can use the built-in commands to do this. There are the F and R keys from the summary buffer which automatically include the article being responded to. These commands are also selectable as Followup and Yank and Reply and Yank in the Post menu.
C-c C-y grabs the previous message and prefixes each line with
ail-indentation-spaces
spaces or mail-yank-prefix
if that is
non-nil, unless you have set your own mail-citation-hook
, which will
be called to do the job.
You might also consider the Supercite package, which allows for pretty arbitrarily complex quoting styles. Some people love it, some people hate it.
How can I most efficiently arrange matters so as to keep my nnvirtual:* (etc) groups at the top of my group selection buffer, whilst keeping everything sorted in alphabetical order. If you don't subscribe often to new groups then the easiest way is to first sort the groups and then manually kill and yank the virtuals wherever you want them.
Here is a collection of suggestions from the Gnus mailing list.
(("Subject" ("^\\(Re: \\)?[^a-z]*$" -200 nil R))) |
(("xref" ("alt.fan.oj-simpson" -1000 nil s)) ("subject" ("\\<\\(make\\|fast\\|big\\)\\s-*\\(money\\|cash\\|bucks?\\)\\>" -1000 nil r) ("$$$$" -1000 nil s))) |
(("subject" ;; CAPS OF THE WORLD, UNITE ("^..[^a-z]+$" -1 nil R) ;; $$$ Make Money $$$ (Try work) ("$" -1 nil s) ;; I'm important! And I have exclamation marks to prove it! ("!" -1 nil s))) |
( (read-only t) ("subject" ;; ALL CAPS SUBJECTS ("^\\([Rr][Ee]: +\\)?[^a-z]+$" -1 nil R) ;; $$$ Make Money $$$ ("$$" -10 nil s) ;; Empty subjects are worthless! ("^ *\\([(<]none[>)]\\|(no subject\\( given\\)?)\\)? *$" -10 nil r) ;; Sometimes interesting announces occur! ("ANN?OU?NC\\(E\\|ING\\)" +10 nil r) ;; Some people think they're on mailing lists ("\\(un\\)?sub?scribe" -100 nil r) ;; Stop Micro$oft NOW!! ("\\(m\\(icro\\)?[s$]\\(oft\\|lot\\)?-?\\)?wind?\\(ows\\|aube\\|oze\\)?[- ]*\\('?95\\|NT\\|3[.]1\\|32\\)" -1001 nil r) ;; I've nothing to buy ("\\(for\\|4\\)[- ]*sale" -100 nil r) ;; SELF-DISCIPLINED people ("\\[[^a-z0-9 \t\n][^a-z0-9 \t\n]\\]" +100 nil r) ) ("from" ;; To keep track of posters from my site (".dgac.fr" +1000 nil s)) ("followup" ;; Keep track of answers to my posts ("boubaker" +1000 nil s)) ("lines" ;; Some people have really nothing to say!! (1 -10 nil <=)) (mark -100) (expunge -1000) ) |
(("subject" ;; No junk mail please! ("please ignore" -500 nil s) ("test" -500 nil e)) ) |
("xref" ;; the more cross posting, the exponentially worse the article ("^xref: \\S-+ \\S-+ \\S-+ \\S-+" -1 nil r) ("^xref: \\S-+ \\S-+ \\S-+ \\S-+ \\S-+" -2 nil r) ("^xref: \\S-+ \\S-+ \\S-+ \\S-+ \\S-+ \\S-+" -4 nil r) ("^xref: \\S-+ \\S-+ \\S-+ \\S-+ \\S-+ \\S-+ \\S-+" -8 nil r) ("^xref: \\S-+ \\S-+ \\S-+ \\S-+ \\S-+ \\S-+ \\S-+ \\S-+" -16 nil r) ("^xref: \\S-+ \\S-+ \\S-+ \\S-+ \\S-+ \\S-+ \\S-+ \\S-+ \\S-+" -32 nil r) ("^xref: \\S-+ \\S-+ \\S-+ \\S-+ \\S-+ \\S-+ \\S-+ \\S-+ \\S-+ \\S-+" -64 nil r) ("^xref: \\S-+ \\S-+ \\S-+ \\S-+ \\S-+ \\S-+ \\S-+ \\S-+ \\S-+ \\S-+ \\S-+" -128 nil r) ("^xref: \\S-+ \\S-+ \\S-+ \\S-+ \\S-+ \\S-+ \\S-+ \\S-+ \\S-+ \\S-+ \\S-+ \\S-+" -256 nil r) ("^xref: \\S-+ \\S-+ \\S-+ \\S-+ \\S-+ \\S-+ \\S-+ \\S-+ \\S-+ \\S-+ \\S-+ \\S-+ \\S-+" -512 nil r)) |
You should probably reply and followup with R and F, instead of r and f, which solves your problem. But you could try something like:
(defconst mail-yank-ignored-headers "^.*:" "Delete these headers from old message when it's inserted in a reply.") |
Now when choosing an URL Gnus starts up a W3 buffer, I would like it to always use Netscape (I don't browse in text-mode ;-).
If you are using XEmacs then to specify Netscape do
(setq gnus-button-url 'gnus-netscape-open-url) |
In order for Gnus to show you the complete list of newsgroups, it will either have to either store the list locally, or ask the server to transmit the list. You enable the first with
(setq gnus-save-killed-list t) |
and the second with
(setq gnus-read-active-file t) |
If both are disabled, Gnus will not know what newsgroups exists. There is no option to get the list by casting a spell.
Per Abrahamsen <abraham@dina.kvl.dk> writes:
Do you call define-key
or something like that in one of the
summary mode hooks? This would force Emacs to recalculate the keyboard
shortcuts. Removing the call should speed up M-x gnus-summary-mode
RET by a couple of orders of magnitude. You can use
(define-key gnus-summary-mode-map KEY COMMAND) |
in your `.gnus' instead.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
A kill-to-score translator was written by Ethan Bradford
<ethanb@ptolemy.astro.washington.edu>. It is available from
`http://baugi.ifi.uio.no/~larsi/ding-various/gnus-kill-to-score.el'.
Don't do that then. The best way to get rid of groups that should be dead is to edit your newsrc directly. This problem will be addressed in the near future.
Put the following into your .gnus:
(add-hook 'nntp-server-opened-hook 'nntp-send-authinfo) |
How do I avoid reading the first article when a group is selected?
(setq gnus-auto-select first nil)
;;; Don't auto-select first article if reading sources, or archives or ;;; jobs postings, etc. and just display the summary buffer (add-hook 'gnus-select-group-hook (function (lambda () (cond ((string-match "sources" gnus-newsgroup-name) (setq gnus-auto-select-first nil)) ((string-match "jobs" gnus-newsgroup-name) (setq gnus-auto-select-first nil)) ((string-match "comp\\.archives" gnus-newsgroup-name) (setq gnus-auto-select-first nil)) ((string-match "reviews" gnus-newsgroup-name) (setq gnus-auto-select-first nil)) ((string-match "announce" gnus-newsgroup-name) (setq gnus-auto-select-first nil)) ((string-match "binaries" gnus-newsgroup-name) (setq gnus-auto-select-first nil)) (t (setq gnus-auto-select-first t)))))) |
((local (gnus-auto-select-first nil))) |
and insert
(setq gnus-auto-select-first t) |
in your `.gnus'.
Brian Edmonds <edmonds@cs.ubc.ca> writes:
Due to changes in Gnus 5.0, `bbdb-gnus.el' no longer marks known
posters in the summary buffer. An updated version, `gnus-bbdb.el'
is available at the locations listed below. This package also supports
autofiling of incoming mail to folders specified in the BBDB. Extensive
instructions are included as comments in the file.
Send mail to `majordomo@edmonds.home.cs.ubc.ca' with the following line in the body of the message: get misc gnus-bbdb.el.
Or get it from the World Wide Web:
`http://www.cs.ubc.ca/spider/edmonds/gnus-bbdb.el'.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Your filter program should not deliver mail directly to your folders, instead it should put the mail into spool files. Gnus will then move the mail safely from the spool files into the folders. This will eliminate the problem. Look it up in the manual, in the section entitled "Mail & Procmail".
I am using nnml to read news and have used
gnus-auto-expirable-newsgroups
to automagically expire articles
in some groups (Gnus being one of them). Sometimes there are
interesting articles in these groups that I want to keep. Is there any
way of explicitly marking an article as un-expirable - that is mark it
as read but not expirable?
Use u, !, d or M-u in the summary buffer. You just remove the E mark by setting some other mark. It's not necessary to tick the articles.
My problem is that I have various mail (nnml) groups generated while
experimenting with Gnus. How do I remove them now? Setting the level to
9 does not help. Also gnus-group-check-bogus-groups
does not
recognize them.
Removing mail groups is tricky at the moment. (It's on the to-do list, though.) You basically have to kill the groups in Gnus, shut down Gnus, edit the active file to exclude these groups, and probably remove the nnml directories that contained these groups as well. Then start Gnus back up again.
I got new mail, but I have never seen the groups they should have been placed in.
They are probably there, but as zombies. Press A z to list zombie groups, and then subscribe to the groups you want with u. This is all documented quite nicely in the user's manual.
How do you totally turn off scoring in mail groups?
Use an nnbabyl:all.SCORE (or nnmh, or nnml, or whatever) file containing:
((adapt ignore) (local (gnus-use-scoring nil)) (exclude-files "all.SCORE")) |
[ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |