nnmaildir uses several group parameters. It's safe to ignore
all this; the default behavior for
nnmaildir is the same as the
default behavior for other mail back ends: articles are deleted after
one week, etc. Except for the expiry parameters, all this
functionality is unique to
nnmaildir, so you can ignore it if
you're just trying to duplicate the behavior you already have with
another back end.
If the value of any of these parameters is a vector, the first element
is evaluated as a Lisp form and the result is used, rather than the
original value. If the value is not a vector, the value itself is
evaluated as a Lisp form. (This is why these parameters use names
different from those of other, similar parameters supported by other
back ends: they have different, though similar, meanings.) (For
t, you can ignore the
eval business again; for other values, remember to use an extra
quote and wrap the value in a vector when appropriate.)
neverto specify that articles should never be expired. If this parameter is not set,
nnmaildirfalls back to the usual
-function) variables (the
expiry-waitgroup parameter overrides
nnmail-expiry-wait-functionineffective). If you wanted a value of 3 days, you could use something like
[(* 3 24 60 60)];
nnmaildirwill evaluate the form and use the result. An article's age is measured starting from the article file's modification time. Normally, this is the same as the article's delivery time, but editing an article makes it younger. Moving an article (other than via expiry) may also make an article younger.
and if it is not the name of the same group that the parameter belongs
to, then articles will be moved to the specified group during expiry
before being deleted. If this is set to an
group, the article will be just as old in the destination group as it
was in the source group. So be careful with
expire-age in the
destination group. If this is set to the name of the same group that
the parameter belongs to, then the article is not expired at all. If
you use the vector form, the first element is evaluated once for each
article. So that form can refer to
nnmaildir-article-file-name, etc., to decide where to put the
article. Even if this parameter is not set,
does not fall back to the
expiry-target group parameter or the
nnmaildirwill treat the articles in this maildir as read-only. This means: articles are not renamed from new/ into cur/; articles are only found in new/, not cur/; articles are never deleted; articles cannot be edited. new/ is expected to be a symlink to the new/ directory of another maildir—e.g., a system-wide mailbox containing a mailing list of common interest. Everything in the maildir outside new/ is not treated as read-only, so for a shared mailbox, you do still need to set up your own maildir (or have write permission to the shared mailbox); your maildir just won't contain extra copies of the articles.
directory-files. It is used to scan the directories in the maildir corresponding to this group to find articles. The default is the function specified by the server's
nnmaildirwill always count the lines of an article, rather than use the
Lines:header field. If
nil, the header field will be used if present.
['(read expire)]. Whenever Gnus asks
nnmaildirfor article marks,
nnmaildirwill say that all articles have these marks, regardless of whether the marks stored in the filesystem say so. This is a proof-of-concept feature that will probably be removed eventually; it ought to be done in Gnus proper, or abandoned if it's not worthwhile.
['(tick expire)]. Whenever Gnus asks
nnmaildirfor article marks,
nnmaildirwill say that no articles have these marks, regardless of whether the marks stored in the filesystem say so.
always-marks. This is a proof-of-concept feature that will probably be removed eventually; it ought to be done in Gnus proper, or abandoned if it's not worthwhile.
nnmaildirkeeps NOV data in memory for a limited number of articles in each group. (This is probably not worthwhile, and will probably be removed in the future.) This parameter's value is noticed only the first time a group is seen after the server is opened—i.e., when you first start Gnus, typically. The NOV cache is never resized until the server is closed and reopened. The default is an estimate of the number of articles that would be displayed in the summary buffer: a count of articles that are either marked with
tickor not marked with
read, plus a little extra.