+
\input texinfo @c -*-texinfo-*-
@setfilename gnus
-@settitle Pterodactyl Gnus 0.80 Manual
+@settitle Pterodactyl Gnus 0.83 Manual
@synindex fn cp
@synindex vr cp
@synindex pg cp
@tex
@titlepage
-@title Pterodactyl Gnus 0.80 Manual
+@title Pterodactyl Gnus 0.83 Manual
@author by Lars Magne Ingebrigtsen
@page
spool or your mbox file. All at the same time, if you want to push your
luck.
-This manual corresponds to Pterodactyl Gnus 0.80.
+This manual corresponds to Pterodactyl Gnus 0.83.
@end ifinfo
Subscribe all new groups hierarchically. The difference between this
function and @code{gnus-subscribe-alphabetically} is slight.
@code{gnus-subscribe-alphabetically} will subscribe new groups in a strictly
-alphabetical fashion, while this function will enter groups into it's
+alphabetical fashion, while this function will enter groups into its
hierarchy. So if you want to have the @samp{rec} hierarchy before the
@samp{comp} hierarchy, this function will not mess that configuration
up. Or something like that.
not stored in the @file{.newsrc} file.
@vindex gnus-save-newsrc-file
+@vindex gnus-read-newsrc-file
You can turn off writing the @file{.newsrc} file by setting
@code{gnus-save-newsrc-file} to @code{nil}, which means you can delete
the file and save some space, as well as exiting from Gnus faster.
However, this will make it impossible to use other newsreaders than
-Gnus. But hey, who would want to, right?
+Gnus. But hey, who would want to, right? Similarly, setting
+@code{gnus-read-newsrc-file} to @code{nil} makes Gnus ignore the
+@file{.newsrc} file and any @file{.newsrc-SERVER} files, which is
+convenient if you have a tendency to use Netscape once in a while.
@vindex gnus-save-killed-list
If @code{gnus-save-killed-list} (default @code{t}) is @code{nil}, Gnus
A hook that is run as the very last thing after starting up Gnus
successfully.
-@item gnus-started-hook
-@vindex gnus-started-hook
+@item gnus-setup-news-hook
+@vindex gnus-setup-news-hook
A hook that is run after reading the @file{.newsrc} file(s), but before
generating the group buffer.
@end ifinfo
@menu
-* Setting Marks:: How to set and remove marks.
-* Setting Process Marks:: How to mark articles for later processing.
+* Setting Marks:: How to set and remove marks.
+* Generic Marking Commands:: How to customize the marking.
+* Setting Process Marks:: How to mark articles for later processing.
@end menu
The default is @code{t}.
+@node Generic Marking Commands
+@subsection Generic Marking Commands
+
+Some people would like the command that ticks an article (@kbd{!}) go to
+the next article. Others would like it to go to the next unread
+article. Yet others would like it to stay on the current article. And
+even though I haven't heard of anybody wanting it to go the the
+previous (unread) article, I'm sure there are people that want that as
+well.
+
+Multiply these five behaviours with five different marking commands, and
+you get a potentially complex set of variable to control what each
+command should do.
+
+To sidestep that mess, Gnus provides commands that do all these
+different things. They can be found on the @kbd{M M} map in the summary
+buffer. Type @kbd{M M C-h} to see them all---there are too many of them
+to list in this manual.
+
+While you can use these commands directly, most users would prefer
+altering the summary mode keymap. For instance, if you would like the
+@kbd{!} command to go the the next article instead of the next unread
+article, you could say something like:
+
+@lisp
+(add-hook 'gnus-summary-mode-hook 'my-alter-summary-map)
+(defun my-alter-summary-map ()
+ (local-set-key "!" 'gnus-summary-put-mark-as-ticked-next))
+@end lisp
+
+or
+
+@lisp
+(defun my-alter-summary-map ()
+ (local-set-key "!" "MM!n"))
+@end lisp
+
+
@node Setting Process Marks
@subsection Setting Process Marks
@cindex setting process marks
(setq gnus-thread-sort-functions
'(gnus-thread-sort-by-number
gnus-thread-sort-by-subject
- (reverse gnus-thread-sort-by-total-score)))
+ (not gnus-thread-sort-by-total-score)))
@end lisp
The threads that have highest score will be displayed first in the
groups adds to all the messages. The way to use this function is to add
the @code{banner} group parameter (@pxref{Group Parameters}) to the
group you want banners stripped from. The parameter either be a string,
-which will be interpreted as a regulax expression matching text to be
+which will be interpreted as a regular expression matching text to be
removed, or the symbol @code{signature}, meaning that the (last)
signature should be removed.
Add clickable buttons to the article headers
(@code{gnus-article-add-buttons-to-head}).
+@item W W H
+@kindex W W H (Summary)
+@findex gnus-article-strip-headers-from-body
+Strip headers like the @code{X-No-Archive} header from the beginning of
+article bodies (@code{gnus-article-strip-headers-from-body}).
+
@item W E l
@kindex W E l (Summary)
@findex gnus-article-strip-leading-blank-lines
'my-save-all-jpeg-parts)
@end lisp
+@vindex gnus-mime-multipart-functions
+@item gnus-mime-multipart-functions
+Alist of @sc{mime} multipart types and functions to handle them.
+
@end table
@item gnus-treat-date-local
@item gnus-treat-date-lapsed
@item gnus-treat-date-original
+@item gnus-treat-strip-headers-in-body
@item gnus-treat-strip-trailing-blank-lines
@item gnus-treat-strip-leading-blank-lines
@item gnus-treat-strip-multiple-blank-lines
@code{nnmail-crosspost-link-function} to @code{copy-file}. (This
variable is @code{add-name-to-file} by default.)
-@findex nnmail-split-header-length-limit
-Header lines may be arbitrarily long. However, the longer a line is,
-the longer it takes to match them. Very long lines may lead to Gnus
-taking forever to split the mail, so Gnus excludes lines that are longer
-than @code{nnmail-split-header-length-limit} (which defaults to 1024).
-
@kindex M-x nnmail-split-history
@kindex nnmail-split-history
If you wish to see where the previous mail split put the messages, you
filter---only files that have the right suffix @emph{and} satisfy this
predicate are considered.
+@item :prescript
+@itemx :postscript
+Script run before/after fetching mail.
+
@end table
An example directory mail source:
@node Fetching Mail
@subsubsection Fetching Mail
+@vindex mail-sources
+@vindex nnmail-spool-file
The way to actually tell Gnus where to get new mail from is to set
-@code{nnmail-spool-file} to a list of mail source specifiers
+@code{mail-sources} to a list of mail source specifiers
(@pxref{Mail Source Specifiers}).
-If this variable is @code{nil}, the mail backends will never attempt to
-fetch mail by themselves.
+If this variable (and the obsolescent @code{nnmail-spool-file}) is
+@code{nil}, the mail backends will never attempt to fetch mail by
+themselves.
If you want to fetch mail both from your local spool as well as a POP
mail server, you'd say something like:
@lisp
-(setq nnmail-spool-file
+(setq mail-sources
'((file)
(pop :server "pop3.mail.server"
:password "secret")))
Or, if you don't want to use any of the keyword defaults:
@lisp
-(setq nnmail-spool-file
+(setq mail-sources
'((file :path "/var/spool/mail/user-name")
(pop :server "pop3.mail.server"
:user "user-name"
(any "debian-\\b\\(\\w+\\)@@lists.debian.org" "mail.debian.\\1")
@end example
+In this example, messages sent to @samp{debian-foo@@lists.debian.org}
+will be filed in @samp{mail.debian.foo}.
+
If the string contains the element @samp{\&}, then the previously
matched string will be substituted. Similarly, the elements @samp{\\1}
up to @samp{\\9} will be substituted with the text matched by the
habit of assuming that you want to read mail with them. This might not
be unreasonable, but it might not be what you want.
-If you set @code{nnmail-spool-file} to @code{nil}, none of the backends
-will ever attempt to read incoming mail, which should help.
+If you set @code{mail-sources} and @code{nnmail-spool-file} to
+@code{nil}, none of the backends will ever attempt to read incoming
+mail, which should help.
@vindex nnbabyl-get-new-mail
@vindex nnmbox-get-new-mail
file is first copied to your home directory. What happens after that
depends on what format you want to store your mail in.
+There are five different mail backends in the standard Gnus, and more
+backends are available separately. The mail backend most people use
+(because it is the fastest and most flexible) is @code{nnml}
+(@pxref{Mail Spool}).
+
@menu
* Unix Mail Box:: Using the (quite) standard Un*x mbox.
* Rmail Babyl:: Emacs programs use the rmail babyl format.
The main way to control what is to be downloaded is to create a
@dfn{category} and then assign some (or all) groups to this category.
-Gnus has its own buffer for creating and managing categories.
+Groups that do not belong in any other category belong to the
+@code{default} category. Gnus has its own buffer for creating and
+managing categories.
@menu
* Category Syntax:: What a category looks like.
@lisp
;;; Define how Gnus is to fetch news. We do this over NNTP
;;; from your ISP's server.
-(setq gnus-select-method '(nntp "nntp.your-isp.com"))
+(setq gnus-select-method '(nntp "news.your-isp.com"))
;;; Define how Gnus is to read your mail. We read mail from
;;; your ISP's POP server.
-(setenv "MAILHOST" "pop.your-isp.com")
-(setq nnmail-spool-file "po:username")
+(setq mail-sources '((pop :server "pop.your-isp.com")))
;;; Say how Gnus is to store the mail. We use nnml groups.
(setq gnus-secondary-select-methods '((nnml "")))
Score on the head.
@item t
-Score on thead.
+Score on thread.
@end table
* Compatibility:: Just how compatible is Gnus with @sc{gnus}?
* Conformity:: Gnus tries to conform to all standards.
* Emacsen:: Gnus can be run on a few modern Emacsen.
+* Gnus Development:: How Gnus is developed.
* Contributors:: Oodles of people.
* New Features:: Pointers to some of the new stuff in Gnus.
* Newest Features:: Features so new that they haven't been written yet.
Emacsen.
+@node Gnus Development
+@subsection Gnus Development
+
+Gnus is developed in a two-phased cycle. The first phase involves much
+discussion on the @samp{ding@@gnus.org} mailing list, where people
+propose changes and new features, post patches and new backends. This
+phase is called the @dfn{alpha} phase, since the Gnusae released in this
+phase are @dfn{alpha releases}, or (perhaps more commonly in other
+circles) @dfn{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
+@dfn{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
+@samp{gnu.emacs.gnus} newsgroup.
+
+@cindex Incoming*
+@vindex nnmail-delete-incoming
+Some variable defaults differ between alpha Gnusae and released Gnusae.
+In particular, @code{nnmail-delete-incoming} defaults to @code{nil} in
+alpha Gnusae and @code{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.
+
+
+
@node Contributors
@subsection Contributors
@cindex contributors
you press `l', point will move to the first instance of the group.
@item
-The documentation should mention pop3.el, fetchmail, smtpmail and why
-po:username often fails.
-
-@item
Fetch by Message-ID from dejanews.
<URL:http://search.dejanews.com/msgid.xp?MID=%3C62h9l9$hm4@@basement.replay.com%3E&fmt=raw>
It should go somewhere else.
@item
+I'm having trouble accessing a newsgroup with a "+" in its name with
+Gnus. There is a new newsgroup on msnews.microsoft.com named
+"microsoft.public.multimedia.directx.html+time" that I'm trying to
+access as
+"nntp+msnews.microsoft.com:microsoft.public.multimedia.directx.html+time"
+but it gives an error that it cant access the group.
+
+Is the "+" character illegal in newsgroup names? Is there any way in
+Gnus to work around this? (gnus 5.6.45 - XEmacs 20.4)
+
+
+@item
Solve the halting problem.
@c TODO
use any other newsreaders than Gnus. This variable is @code{t} by
default.
+@item gnus-read-newsrc-file
+If this is @code{nil}, Gnus will never read @file{.newsrc}---it will
+only read @file{.newsrc.eld}. This means that you will not be able to
+use any other newsreaders than Gnus. This variable is @code{t} by
+default.
+
@item gnus-save-killed-list
If this is @code{nil}, Gnus will not save the list of dead groups. You
should also set @code{gnus-check-new-newsgroups} to @code{ask-server}
projects / elisp / gnus.git- / blobdiff