All them variables, they make my head swim.
So what if you want a different Organization
and signature based
on what groups you post to? And you post both from your home machine
and your work machine, and you want different From
lines, and so
on?
One way to do stuff like that is to write clever hooks that change the
variables you need to have changed. That's a bit boring, so somebody
came up with the bright idea of letting the user specify these things in
a handy alist. Here's an example of a gnus-posting-styles
variable:
((".*" (signature "Peace and happiness") (organization "What me?")) ("^comp" (signature "Death to everybody")) ("comp.emacs.i-love-it" (organization "Emacs is it")))
As you might surmise from this example, this alist consists of several
styles. Each style will be applicable if the first element
"matches", in some form or other. The entire alist will be iterated
over, from the beginning towards the end, and each match will be
applied, which means that attributes in later styles that match override
the same attributes in earlier matching styles. So
`comp.programming.literate' will have the `Death to everybody'
signature and the `What me?' Organization
header.
The first element in each style is called the match
. If it's a
string, then Gnus will try to regexp match it against the group name.
If it is the symbol header
, then Gnus will look for header (the
next element in the match) in the original article , and compare that to
the last regexp in the match. If it's a function symbol, that function
will be called with no arguments. If it's a variable symbol, then the
variable will be referenced. If it's a list, then that list will be
eval
ed. In any case, if this returns a non-nil
value,
then the style is said to match.
Each style may contain a arbitrary amount of attributes. Each
attribute consists of a (name value)
pair. The
attribute name can be one of signature
, signature-file
,
organization
, address
, name
or body
. The
attribute name can also be a string. In that case, this will be used as
a header name, and the value will be inserted in the headers of the
article; if the value is nil
, the header name will be removed.
If the attribute name is eval
, the form is evaluated, and the
result is thrown away.
The attribute value can be a string (used verbatim), a function with
zero arguments (the return value will be used), a variable (its value
will be used) or a list (it will be eval
ed and the return value
will be used). The functions and sexps are called/eval
ed in the
message buffer that is being set up. The headers of the current article
are available through the message-reply-headers
variable.
If you wish to check whether the message you are about to compose is
meant to be a news article or a mail message, you can check the values
of the message-news-p
and message-mail-p
functions.
So here's a new example:
(setq gnus-posting-styles '((".*" (signature-file "~/.signature") (name "User Name") ("X-Home-Page" (getenv "WWW_HOME")) (organization "People's Front Against MWM")) ("^rec.humor" (signature my-funny-signature-randomizer)) ((equal (system-name) "gnarly") (signature my-quote-randomizer)) ((message-news-p) (signature my-news-signature)) (header "to" "larsi.*org" (Organization "Somewhere, Inc.")) ((posting-from-work-p) (signature-file "~/.work-signature") (address "user@bar.foo") (body "You are fired.\n\nSincerely, your boss.") (organization "Important Work, Inc")) ("nnml:.*" (From (save-excursion (set-buffer gnus-article-buffer) (message-fetch-field "to")))) ("^nn.+:" (signature-file "~/.mail-signature"))))
The `nnml:.*' rule means that you use the To
address as the
From
address in all your outgoing replies, which might be handy
if you fill many roles.
Go to the first, previous, next, last section, table of contents.