Gnus development mailing list
 help / color / mirror / Atom feed
From: lee <lee@yun.yagibdah.de>
To: ding@gnus.org
Subject: Re: Gnus Questions #1: Article Expiry
Date: Mon, 04 Jul 2011 16:29:18 +0200	[thread overview]
Message-ID: <87sjqm15mp.fsf@yun.yagibdah.de> (raw)
In-Reply-To: <m2d3hr9c34.fsf@pluto.luannocracy.com> (Dave Abrahams's message of "Sun, 03 Jul 2011 19:30:23 -0400")

Dave Abrahams <dave@boostpro.com> writes:

> * I presume that "expiring" an article means the same as "putting the
>   article through the expiry process" (?)

Well, when I mark an article `E', I'm "expiring" it.  It'll be purged
some time later --- apparently only *if* I enter and leave the group the
article is in later.  If I don't, the article will never be purged: is
that true?

> * What's the difference between `gnus-summary-expire-articles' and
>   `gnus-summary-expire-articles-now'?  The documentation doesn't make
>   that clear.

The difference is in "delete all expirable articles in the group /that
have been around for a while/" vs. "This means that *all* articles
eligible for expiry in the current group will disappear" /right now/.
The documentation could be more clear on this, like:


,----
| `B e'
|      Perform an expiry process on the articles in the current
|      group. Only articles that are expirable *and due to be purged*
|      will be purged.  The expiry process is performed by the function
|      `gnus-summary-expire-articles'.  (See Expiring Mail::).
| 
| `B C-M-e'
|      Purge all the expirable articles in the current group *right
|      now*. This means that all expirable articles will be purged
|      immediately.  The purging process is performed by the function
|      `gnus-summary-expire-articles-now'.  (See Expiring Mail::).
`----

How about renaming "gnus-summary-expire-articles-now" to
"gnus-summary-purge-articles" (or to "gnus-purge-articles")?

There also needs to be some clarification about what "expiring" means.
There seem to be actually quite a few stages of expirableness:

* not expirable, depends on gnus-inhibit-user-auto-expire,
                            nnfolder-inhibit-expiry??
* marked as `E', depends on age
* marked as `r', depends on age, total-expire
* marked as `R', depends on age, total-expire
* marked as `O', depends on age, total-expire
* marked as `K', depends on age, total-expire
* marked as `Y', depends on age, total-expire
* marked as "and so on"[1], apparently depends total-expire only
* marked as `G': depends on gnus-inhibit-user-auto-expire,
                            nnfolder-inhibit-expiry??


Then there's the purgability of articles.  It seems that articles marked
`G' are always purged on leaving a group.  Perhaps they cannot be purged
eventually, depending on some settings (and marks, maybe):

,---- [ info:gnus#Expiring Mail ]
|    If `gnus-inhibit-user-auto-expire' is non-`nil', user marking
| commands will not mark an article as expirable, even if the group has
| auto-expire turned on.
`----

This mentions marking only. Will articles in stages of expirableness
eventually be purged nonetheless?

What disables the purgability of an article?


[1] {
      ,---- [ info:gnus#Expiring Mail ]
      | So, in addition to the articles marked `E', also the articles
      | marked `r', `R', `O', `K', `Y' and so on are considered
      | expirable.
      `----

      What other marks are there?  Can I prevent articles from being
      marked as `O' automatically?  What means `r`?  Can I configure
      which marks put articles into stages of expirableness? There needs
      to be an overview of the possible marks in the chapter about
      expiring mail, or somewhere.
}

> * What's the point of backend-specific expiry settings like
>   nnfolder-inhibit-expiry (I'm referring to the `nnfolder-' part when I
>   say `backend-specific')?  Don't we have enough other ways to say "this
>   group/server isn't expirable?"

Hm, nnfolder-inhibit-expiry doesn't seem to be explained in the
documentation.  What does it inhibit, the purgability or the
expirableness?

Which other ways to say that a server/group isn't expirable (or
purgeable, which is a difference) have you found?

Is there a way to request information about the expirableness and
purgability of articles? You'd get an information like "This article is
[not expirable | expired | expirable and will expire when ...] because
.... This article is [not purgable | purgable and will be purged when
...] because ....".  Gnus must have some way of figuring this out to be
able to expire and purge articles correctly.

> * [[info:gnus#Expiring Mail]] mentions `having auto expiry switched on'
>   but doesn't say how to do that.  Are we talking about the auto-expire
>   group parameter here, or something else?

Yeah, it should be clarified.

> * "Total Expire" and "Auto Expire"
>
>   * The main point of using "Total Expire" instead of "Auto Expire"
>     seems to be that with "total expire" you can keep a distinction
>     between expirable (`E') and other marks that indicate an article was
>     read... until expiry actually runs.  At that point, if you're using
>     total expire they're all treated the same.  With "auto expire," on
>     the other hand, you know that only articles marked `E' will be
>     put through the expiry process.

Yes: Total-expire makes articles purgeable *without* marking
them. Auto-expire makes articles purgeable *by* marking them.

>   * From [[info:gnus#Adaptive Scoring]] I think I conclude that adaptive
>     scoring takes effect at expiry time, and "auto-expire" changes all
>     read marks to `E' too early for adaptive scoring to do its work.  Is
>     that right?

Non-adaptive scoring seems to happen when you enter a group.  Each time
you enter the group, the scoring rules are applied, resulting in
incredible scores.  I wonder what the idea behind this way of
implementing it is.  Is that different with adaptive scoring?

>     Okay, now that I read it again I think it's saying that with
>     "auto-expire," if I can somehow produce a mark other than `E' for an
>     article that's been read,, that article can persist even if it's
>     neither dormant or ticked.  That's fine as far as it goes but
>     mentioning it seems almost pointless, since Gnus is going to
>     automatically mark everything I read as `E'.  What am I missing?

Auto-expire does *not* lead to eventually purging articles you don't
touch, while total-expire *does* lead to eventually purging articles you
don't touch (because gnus touches them with scoring and `O' marks, for
example).

>   * This (from [[info:gnus#Expiring Mail]]) seems confusing for what I
>     think are related reasons:
>    
>      ,----
>      | Note that making a group auto-expirable doesn't mean that all read
>      | articles are expired--only the articles marked as expirable will be
>      | expired
>      `----
>
>     If auto-expire automatically marks articles expirable when you read
>     them, doesn't that /necessarily/ mean all read articles are expired
>     (except articles you read in the past?).

The documentation somewhat struggles trying to explain that the
auto-expire option doesn't do anything else than marking articles with
`E' when they otherwise would be marked `R'.

To say just that and not much more would probably suffice.


Thinking of this, what's the point behind gnus changing marks
automatically?  When I mark something read, it'll later be marked `O'.
When marking something as killed, that doesn't seem to be any different
from marking it as read (unless you use adaptive scoring maybe).  Gnus
automatically marks it as `O' as well.

Why doesn't gnus keep the distinction between "read" and "killed"?  When
I enter a group after having killed some of the threads, I still want to
be able to see what threads I've killed, what I have actually read and
what I didn't read but "cought up" with.  I don't trust the scoring
because it might hide things from me I want to see, so seeing what I
read, killed and cought up with is an important information to me.

Can't gnus mark as `R' what I've read, as `K' what I've killed and
as `O' what I cought up with and keep these marks intact?


-- 
html messages are obsolete



  reply	other threads:[~2011-07-04 14:29 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-03 23:30 Dave Abrahams
2011-07-04 14:29 ` lee [this message]
2011-07-05  0:50   ` Dave Abrahams
2011-07-05 21:51     ` lee
2011-07-05 22:46       ` lee
2011-07-06 18:32         ` Dave Abrahams
2011-07-06 19:24           ` lee
2011-07-05 20:44 ` Lars Magne Ingebrigtsen
2011-07-06 18:28   ` Dave Abrahams
2011-07-06 19:55     ` lee
2011-07-06 20:00     ` Dan Christensen
2011-07-19 16:32     ` Lars Magne Ingebrigtsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87sjqm15mp.fsf@yun.yagibdah.de \
    --to=lee@yun.yagibdah.de \
    --cc=ding@gnus.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).