Gnus development mailing list
 help / color / mirror / Atom feed
From: Dave Abrahams <dave@boostpro.com>
To: ding@gnus.org
Subject: Gnus Questions #1: Article Expiry
Date: Sun, 03 Jul 2011 19:30:23 -0400	[thread overview]
Message-ID: <m2d3hr9c34.fsf@pluto.luannocracy.com> (raw)


Hi Lars and all,

I am attempting a return to Gnus...

...but I've decided that this time around I can't afford to do that
without actually grokking the system I'm using.  I've been reading
carefully through the manual and doing some experiments so I can verify
my understanding, such as it is.

I'm also growing a list of questions. I'll try to separate them by topic
and contribute doc patches on the basis of the answers.  Please also
correct any false statements below:

* What's the difference between marking an article "expirable (E)" and
  `marking it expired' as described by [[info:gnus#Spam and Ham
  Processors]]?

* [[info:gnus#Expiring Mail]] and [[info:gnus#Group Parameters]] both
  mention articles being `put through the expiry process,' but that
  process is never spelled out.  What exactly is involved?

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

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

* 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?"

* [[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?

* "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.

  * 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?
   
  * [[info:gnus#Expiring Mail]] seems to contradict my understanding,
    though: it claims that "auto-expire" gives me "more marks to work
    with."

    ,----
    | Another advantage of auto-expire is that you get more marks to work
    | with: for the articles that are supposed to stick around, you can
    | still choose between tick and dormant and read marks.  But with
    | total-expire, you only have dormant and ticked to choose from
    `----

    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?

  * 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?).  Is there a common usage
    model where people set auto-expire and then use some explicit
    commands to change the read mark on some of their articles after
    Gnus has already marked them `E'?

  * Aren't there a bajillion other ways to do the following, including
    by customizing the "auto-expire" group parameter?  Why would I do it
    as below (see [[info:gnus#Expiring Mail]]) instead?
   
    ,----
    | To avoid having articles marked as read marked as
    | expirable automatically, you can put something like the following in
    | your `~/.gnus.el' file:
    | 
    |      (remove-hook 'gnus-mark-article-hook
    |                   'gnus-summary-mark-read-and-unread-as-read)
    |      (add-hook 'gnus-mark-article-hook 'gnus-summary-mark-unread-as-read)
    | 
    `----
    

* How does the expire-age group parameter come into play?
  - Does it prevent me from marking articles as expirable for a period?
  - Does it prevent auto-expire from marking articles expirable?
  - Does it simply exempt articles that are too young from expiry?

* Suggestion: Rename `gnus-auto-expirable-newsgroups'
  `gnus-auto-expirable-groups' since, generally, auto-expire only
  applies to mail and not to nntp.
      
* As far as I can tell, the user experience of Agent expiry is
  completely different from that of regular article expiry.  This isn't
  explained anywhere, but IIUC from experiments, agent expiry doesn't
  delete any mail except from the agent's cache.  Instead it merely
  flushes (some part of) the agent's cache.  Is that right?

  I and several of my friends have long been plagued by the symptom that
  if I delete an IMAP message in some other mail client, it still hangs
  around in Gnus.  I've beat my head against
  `gnus-agent-regenerate[-group]' and `gnus-agent-flush-*' and other
  trix for years trying to correct it, but never found a reliable
  formula.  Agent expiry seems to be the key.  I think.  Have I got that
  right?

Thanks for taking the time with these questions,

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com





             reply	other threads:[~2011-07-03 23:30 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-03 23:30 Dave Abrahams [this message]
2011-07-04 14:29 ` lee
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=m2d3hr9c34.fsf@pluto.luannocracy.com \
    --to=dave@boostpro.com \
    --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).