(@code{gnus-summary-limit-to-author}). If given a prefix, exclude
matching articles.
+@item / R
+@kindex / R (Summary)
+@findex gnus-summary-limit-to-recipient
+Limit the summary buffer to articles that match some recipient
+(@code{gnus-summary-limit-to-recipient}). If given a prefix, exclude
+matching articles.
+
@item / x
@kindex / x (Summary)
@findex gnus-summary-limit-to-extra
@findex gnus-thread-sort-by-score
@findex gnus-thread-sort-by-subject
@findex gnus-thread-sort-by-author
+@c @findex gnus-thread-sort-by-recipient
@findex gnus-thread-sort-by-number
@findex gnus-thread-sort-by-random
@vindex gnus-thread-sort-functions
@findex gnus-summary-sort-by-author
Sort by author (@code{gnus-summary-sort-by-author}).
+@item C-c C-s C-t
+@kindex C-c C-s C-t (Summary)
+@findex gnus-summary-sort-by-recipient
+Sort by recipient (@code{gnus-summary-sort-by-recipient}).
+
@item C-c C-s C-s
@kindex C-c C-s C-s (Summary)
@findex gnus-summary-sort-by-subject
argument. It should return a non-@code{nil} value if it thinks that the
mail belongs in that group.
+@cindex @samp{bogus} group
The last of these groups should always be a general one, and the regular
-expression should @emph{always} be @samp{*} so that it matches any mails
+expression should @emph{always} be @samp{""} so that it matches any mails
that haven't been matched by any of the other regexps. (These rules are
-processed from the beginning of the alist toward the end. The first
-rule to make a match will ``win'', unless you have crossposting enabled.
-In that case, all matching rules will ``win''.) When new groups are
-created by splitting mail, you may want to run
-@code{gnus-group-find-new-groups} to see the new groups.
+processed from the beginning of the alist toward the end. The first rule
+to make a match will ``win'', unless you have crossposting enabled. In
+that case, all matching rules will ``win''.) If no rule matched, the mail
+will end up in the @samp{bogus} group. When new groups are created by
+splitting mail, you may want to run @code{gnus-group-find-new-groups} to
+see the new groups. This also applies to the @samp{bogus} group.
If you like to tinker with this yourself, you can set this variable to a
function of your choice. This function will be called without any
The mail back ends all support cross-posting. If several regexps match,
the mail will be ``cross-posted'' to all those groups.
@code{nnmail-crosspost} says whether to use this mechanism or not. Note
-that no articles are crossposted to the general (@samp{*}) group.
+that no articles are crossposted to the general (@samp{""}) group.
@vindex nnmail-crosspost-link-function
@cindex crosspost
Make sure you read the section on the @code{spam.el} sequence of
events. See @xref{Spam ELisp Package Sequence of Events}.
+@cindex spam-initialize
To use @code{spam.el}, you @strong{must} run the function
-@code{spam-initialize} to autoload @code{spam.el} and to install the
+@code{spam-initialize} to autoload @file{spam.el} and to install the
@code{spam.el} hooks. There is one exception: if you use the
@code{spam-use-stat} (@pxref{spam-stat spam filtering}) setting, you
should turn it on before @code{spam-initialize}:
(spam-initialize)
@end example
-So, what happens when you load @code{spam.el}?
+So, what happens when you load @file{spam.el}?
First, some hooks will get installed by @code{spam-initialize}. There
are some hooks for @code{spam-stat} so it can save its databases, and
@end table
-Also, when you load @code{spam.el}, you will be able to customize its
+Also, when you load @file{spam.el}, you will be able to customize its
variables. Try @code{customize-group} on the @samp{spam} variable
group.
You should still have specific checks such as
@code{spam-use-regex-headers} set to @code{t}, even if you
specifically invoke @code{spam-split} with the check. The reason is
-that when loading @code{spam.el}, some conditional loading is done
+that when loading @file{spam.el}, some conditional loading is done
depending on what @code{spam-use-xyz} variables you have set. This
is usually not critical, though.
@code{spam-use-bogofilter}, the @code{X-Bogosity} header will be used.
If you use @code{spam-use-crm114}, any header that matches the CRM114
score format will be used. As long as you set the appropriate back end
-variable to t @emph{before} you load @code{spam.el}, you will be
+variable to t @emph{before} you load @file{spam.el}, you will be
fine. @code{spam.el} will automatically add the right header to the
internal Gnus list of required headers.
projects / elisp / gnus.git- / blobdiff