Re: Why expiry of drafts?

[Kai Grossjohann]

Adrian Lanz <lanz@fowi.ethz.ch> writes:

> On 26 Apr 2004, kai@emptydomain.de wrote:
>
> From a user's perspective, there is the logic to specify select
> methods (backend end + server name) through variable
> gnus-secondary-select-methods, and there should be - for the expiry
> thing configureable through variables nnmail-expiry-target,
> gnus-*-expirable-newsgroups and nnmail-expiry-wait-function - an
> additional logic to specify the "expiry flow" from one (or several)
> select methods to one (or several) other select methods. In this
> contect, flow configuration should accept fully qualified group names.

Well, the *target* group names are already fully qualified, so I don't
see what else is needed here.

But maybe you need different expiry targets for different (input)
servers.  In that case it *might* work to specify the value of
nnmail-fancy-expiry-targets separately for each server.  Hm.  Perhaps
it works to specify the variable in gnus-parameters?

> This brings me to mind: A similar generalized mechanism should also be
> available for incoming mail. Here we specify the mail-sources and the
> flow from sources to select methods through nnmail-split-methods. What
> happens, when there are several select methods with *-get-new-mail set
> to t? I never tried. The logic - from a user's point of view - should
> be to specify this flow (from mail sources to select methods) in
> variable nnmail-split-methods. Thus, in a ideal Gnus world,
> nnmail-split-methods would accept fully qualified group names to split
> incoming mail from one (or many) mail sources to one (or many) select
> methods.

I think you can add a server parameter for mail-sources:

(add-to-list 'gnus-secondary-select-methods
             '(nnml "" (mail-sources ...)))
;;                     ^^^^^^^^^^^^^^^^^^

>>>
>>> So if ever expiring of messages happens, it should be only in
>>> "nnfolder\\+mail:.*" groups (definitively not in the
>>> "nndraft:drafts" group), after 5 (spam) or 30 days (not immediately
>>> as it seems to be the case for drafts) and into a subdirectory of
>>> "/home/lanz/mail/gnus/expired/" (not "/home/lanz/mail/gnus/" as for
>>> drafts).
>>
>> No, no, no.  Total-expire means that Gnus considers read articles
>> (marks r, R, K, Y and so on) to be expirable, in addition to the
>> articles explicitly marked as expirable (mark E).
>>
>> If you mark a message as expirable, using the E key (not e), then it
>> will be expirable in any group.  You can set nnchoke-inhibit-expiry,
>> and you can tweak expiry-wait, but you didn't do any of those for
>> nndraft:drafts.
>
> I am not understanding you here. For me, there are two problems which
> are not necessarily (but may be) related. Why is Gnus expiring my
> drafts immediately after sending the finished article (this should not
> happen),

Well, this seems to be a bug: article deletion also works like expiry,
and the draft article clearly needs to be deleted when you send it.

> and why does Gnus send the expired drafts to a place I would not
> expect it to send it to?

This seems to be another bug...

> 1) What is the reason, that drafts get expired with my settings? (BTW,
>    I think it is expiry, may be it just seems to be expiry? See the
>    details in my first mail.) Does this happen for you? How do you
>    specify mail that should get total (or auto) expired and its
>    targets. Do I use some special configuration?  The documentation of
>    variable gnus-total-expirable-newsgroups says:
>
>    *Groups in which to perform expiry of all read articles. Use with
                                           ^^^^^^^^

>    extreme caution.  All groups that match this regexp will be
>    expiring - which means that all read articles will be deleted after
>    (say) one week.  (This only goes for mail groups and the like, of
>    course.)
>
>    With (setq gnus-total-expirable-newsgroups "nnfolder\\+mail:.*"), I
>    conclude, that expiry should never happen in nndrafts.

This variable has nothing to do with the problem: if total expire is
off, this only means that fewer articles are expired, not that no
articles will be expired.

And the articles you are talking about (the drafts) are not affected
by this variable.

> 2) I keep incoming mail in nnfolder+mail: and expired articles in
>    nnml+expired:, both backends being configured in variable
>    gnus-secondary-select-methods. No problems with that. But an
>    article expired from the draft group (which BTW should never
>    happen, see point 1 above), does not respect the nnmail+expired:
>    settings, but "invents" a new expiry server, which seems to be a
>    nnml: server (which is not configured and does not appear in the
>    server buffer) in a default directory. Why is Gnus not using the
>    nnml+expired: server, i.e. respecting the nnml-directory (and other
>    server variables) configured in the gnus-secondary-select-methods
>    variable? And also, why are the drafts expired immediately?

I think this is a bug.

Kai