html2
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
All commands for posting and mailing will put you in a message buffer where you can edit the article all you like, before you send the article by pressing C-c C-c. See section `Top' in The Message Manual. Where the message will be posted/mailed to depends on your setup (see section 5.3 Posting Server).
5.1 Mail Mailing and replying. 5.2 Post Posting and following up. 5.3 Posting Server What server should you post via? 5.4 Mail and Post Mailing and posting at the same time. 5.5 Archived Messages Where Gnus stores the messages you've sent. 5.6 Posting Styles An easier way to specify who you are. 5.7 Drafts Postponing messages and rejected messages. 5.8 Rejected Articles What happens if the server doesn't like your article?
Also see see section 3.5.4 Canceling Articles for information on how to remove articles you shouldn't have posted.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Variables for customizing outgoing mail:
gnus-uu-digest-headers
gnus-add-to-list
nil
, add a to-list
group parameter to mail groups
that have none when you do a a.
message-send-mail-partially-limit
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Variables for composing news articles:
gnus-sent-message-ids-file
Message-ID
history file of all the mails it has
sent. If it discovers that it has already sent a mail, it will ask the
user whether to re-send the mail. (This is primarily useful when
dealing with SOUP packets and the like where one is apt to send the
same packet multiple times.) This variable says what the name of this
history file is. It is `~/News/Sent-Message-IDs' by default. Set
this variable to nil
if you don't want Gnus to keep a history
file.
gnus-sent-message-ids-length
Message-ID
s to keep in the history
file. It is 1000 by default.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
When you press those magical C-c C-c keys to ship off your latest (extremely intelligent, of course) article, where does it go?
Thank you for asking. I hate you.
It can be quite complicated. Normally, Gnus will use the same native
server. However. If your native server doesn't allow posting, just
reading, you probably want to use some other server to post your
(extremely intelligent and fabulously interesting) articles. You can
then set the gnus-post-method
to some other method:
(setq gnus-post-method '(nnspool "")) |
Now, if you've done this, and then this server rejects your article, or this server is down, what do you do then? To override this variable you can use a non-zero prefix to the C-c C-c command to force using the "current" server for posting.
If you give a zero prefix (i.e., C-u 0 C-c C-c) to that command, Gnus will prompt you for what method to use for posting.
You can also set gnus-post-method
to a list of select methods.
If that's the case, Gnus will always prompt you for what method to use
for posting.
Finally, if you want to always post using the same select method as
you're reading from (which might be convenient if you're reading lots of
groups from different private servers), you can set this variable to
current
.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Here's a list of variables relevant to both mailing and posting:
gnus-mailing-list-groups
If your news server offers groups that are really mailing lists
gatewayed to the NNTP server, you can read those groups without
problems, but you can't post/followup to them without some difficulty.
One solution is to add a to-address
to the group parameters
(see section 2.10 Group Parameters). An easier thing to do is set the
gnus-mailing-list-groups
to a regexp that matches the groups that
really are mailing lists. Then, at least, followups to the mailing
lists will work most of the time. Posting to these groups (a) is
still a pain, though.
You may want to do spell-checking on messages that you send out. Or, if
you don't want to spell-check by hand, you could add automatic
spell-checking via the ispell
package:
(add-hook 'message-send-hook 'ispell-message) |
If you want to change the ispell
dictionary based on what group
you're in, you could say something like the following:
(add-hook 'gnus-select-group-hook (lambda () (cond ((string-match "^de\\." gnus-newsgroup-name) (ispell-change-dictionary "deutsch")) (t (ispell-change-dictionary "english"))))) |
Modify to suit your needs.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Gnus provides a few different methods for storing the mail and news you
send. The default method is to use the archive virtual server to
store the messages. If you want to disable this completely, the
gnus-message-archive-group
variable should be nil
, which
is the default.
gnus-message-archive-method
says what virtual server Gnus is to
use to store sent messages. The default is:
(nnfolder "archive" (nnfolder-directory "~/Mail/archive") (nnfolder-active-file "~/Mail/archive/active") (nnfolder-get-new-mail nil) (nnfolder-inhibit-expiry t)) |
You can, however, use any mail select method (nnml
,
nnmbox
, etc.). nnfolder
is a quite likeable select method
for doing this sort of thing, though. If you don't like the default
directory chosen, you could say something like:
(setq gnus-message-archive-method '(nnfolder "archive" (nnfolder-inhibit-expiry t) (nnfolder-active-file "~/News/sent-mail/active") (nnfolder-directory "~/News/sent-mail/"))) |
Gnus will insert Gcc
headers in all outgoing messages that point
to one or more group(s) on that server. Which group to use is
determined by the gnus-message-archive-group
variable.
This variable can be used to do the following:
Note that you can include a select method in the group name, then the
message will not be stored in the select method given by
gnus-message-archive-method
, but in the select method specified
by the group name, instead. Suppose gnus-message-archive-method
has the default value shown above. Then setting
gnus-message-archive-group
to "foo"
means that outgoing
messages are stored in `nnfolder+archive:foo', but if you use the
value "nnml:foo"
, then outgoing messages will be stored in
`nnml:foo'.
nil
No message archiving will take place. This is the default.
Let's illustrate:
Just saving to a single group called `MisK':
(setq gnus-message-archive-group "MisK") |
Saving to two groups, `MisK' and `safe':
(setq gnus-message-archive-group '("MisK" "safe")) |
Save to different groups based on what group you are in:
(setq gnus-message-archive-group '(("^alt" "sent-to-alt") ("mail" "sent-to-mail") (".*" "sent-to-misc"))) |
More complex stuff:
(setq gnus-message-archive-group '((if (message-news-p) "misc-news" "misc-mail"))) |
How about storing all news messages in one file, but storing all mail messages in one file per month:
(setq gnus-message-archive-group '((if (message-news-p) "misc-news" (concat "mail." (format-time-string "%Y-%m"))))) |
(XEmacs 19.13 doesn't have format-time-string
, so you'll have to
use a different value for gnus-message-archive-group
there.)
Now, when you send a message off, it will be stored in the appropriate
group. (If you want to disable storing for just one particular message,
you can just remove the Gcc
header that has been inserted.) The
archive group will appear in the group buffer the next time you start
Gnus, or the next time you press F in the group buffer. You can
enter it and read the articles in it just like you'd read any other
group. If the group gets really big and annoying, you can simply rename
if (using G r in the group buffer) to something
nice---`misc-mail-september-1995', or whatever. New messages will
continue to be stored in the old (now empty) group.
That's the default method of archiving sent messages. Gnus offers a
different way for the people who don't like the default method. In that
case you should set gnus-message-archive-group
to nil
;
this will disable archiving.
gnus-outgoing-message-group
If you want to have greater control over what group to put each message in, you can set this variable to a function that checks the current newsgroup name and then returns a suitable group name (or list of names).
This variable can be used instead of gnus-message-archive-group
,
but the latter is the preferred method.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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 that
match the next element in the match, and compare that to the last header
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 "From\\|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.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
If you are writing a message (mail or news) and suddenly remember that you have a steak in the oven (or some pesto in the food processor, you craaazy vegetarians), you'll probably wish there was a method to save the message you are writing so that you can continue editing it some other day, and send it when you feel its finished.
Well, don't worry about it. Whenever you start composing a message of some sort using the Gnus mail and post commands, the buffer you get will automatically associate to an article in a special draft group. If you save the buffer the normal way (C-x C-s, for instance), the article will be saved there. (Auto-save files also go to the draft group.)
The draft group is a special group (which is implemented as an
nndraft
group, if you absolutely have to know) called
`nndraft:drafts'. The variable nndraft-directory
says where
nndraft
is to store its files. What makes this group special is
that you can't tick any articles in it or mark any articles as
read--all articles in the group are permanently unread.
If the group doesn't exist, it will be created and you'll be subscribed to it. The only way to make it disappear from the Group buffer is to unsubscribe it.
When you want to continue editing the article, you simply enter the
draft group and push D e (gnus-draft-edit-message
) to do
that. You will be placed in a buffer where you left off.
Rejected articles will also be put in this draft group (see section 5.8 Rejected Articles).
If you have lots of rejected messages you want to post (or mail) without
doing further editing, you can use the D s command
(gnus-draft-send-message
). This command understands the
process/prefix convention (see section 8.1 Process/Prefix). The D S
command (gnus-draft-send-all-messages
) will ship off all messages
in the buffer.
If you have some messages that you wish not to send, you can use the
D t (gnus-draft-toggle-sending
) command to mark the message
as unsendable. This is a toggling command.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Sometimes a news server will reject an article. Perhaps the server doesn't like your face. Perhaps it just feels miserable. Perhaps there be demons. Perhaps you have included too much cited text. Perhaps the disk is full. Perhaps the server is down.
These situations are, of course, totally beyond the control of Gnus. (Gnus, of course, loves the way you look, always feels great, has angels fluttering around inside of it, doesn't care about how much cited text you include, never runs full and never goes down.) So Gnus saves these articles until some later time when the server feels better.
The rejected articles will automatically be put in a special draft group (see section 5.7 Drafts). When the server comes back up again, you'd then typically enter that group and send all the articles off.
[ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |