Gnus development mailing list
 help / color / mirror / Atom feed
From: Dave Abrahams <dave@boostpro.com>
To: ding@gnus.org
Subject: Re: Gnus Questions #1: Article Expiry
Date: Wed, 06 Jul 2011 14:28:58 -0400	[thread overview]
Message-ID: <m2vcvfxnyt.fsf@pluto.luannocracy.com> (raw)
In-Reply-To: <m3vcvgsbiq.fsf@quimbies.gnus.org>


Hi Lars,

Let me say in advance, thanks a lot for your answers.  Where I have
elided text you wrote below, please assume my response is, "got it,
thanks."

on Tue Jul 05 2011, Lars Magne Ingebrigtsen <larsi-AT-gnus.org> wrote:

> Dave Abrahams <dave@boostpro.com> writes:
>
>> * What's the difference between marking an article "expirable (E)" and
>>   `marking it expired' as described by [[info:gnus#Spam and Ham
>>   Processors]]?
>
> I'm not that familiar with the spam processing thing, so I'm not sure.
> I mean, there is no mark for "expired articles" (i.e. deleted articles)
> as far as I know.  Just "expirable articles".

I agree and am inclined to think we need to s/expired/expirable/ in the
referenced info node.  I'll put that in my patch.

>> * [[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?
>
> It's what's described on the "Expiring Mail" node?

Sorry to be a pain, but that doesn't look like a description of a
process to me.  It looks like a description of a bunch of settings and
the effects they have, but there's nothing like "first this happens,
then we do that, ..."


>> * What's the difference between `gnus-summary-expire-articles' and
>>   `gnus-summary-expire-articles-now'?  The documentation doesn't make
>>   that clear.
>
> The latter says:
>
> "This means that *all* articles that are marked as expirable will be
> deleted forever, right now."

Of course I've read that line over and over and it isn't getting
clearer.  As I wrote to Lee,

,----
| Yeah, I read all those words, but they didn't add up to any obvious
| distinction for me. The phrases "have been around for a while" and
| "eligible for expiry" are vague at best.  By contrast the use of
| "delete" and "disappear" seem implausibly concrete for a system whose
| expiration behavior can range from "do nothing" (which is undocumented,
| but that's what you get from nnimap if the expiry target is nil) to
| "forward the article to my mother-in-law" (if I write the function to do
| that).  I would rather say that the articles are "sent to the group's
| expiry target" (a phrase I'd suitably define in Expiring Mail::).
`----

>> * "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.
>
> Well, sort of.  With total expire, you expire all old articles.  

Do you really mean "old?" The doc seems to say you expire all articles
with a read mark.

> If you don't use total expire, the expiration process will only
> consider "E"-marked articles.
>
> You can "E"-mark them manually, or you can switch on auto-expire and
> have Gnus set the "E" mark automatically.

OK.

>>   * 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?
>
> No.  If you set the "E" mark on all articles (whether automatically or
> manually), Adaptive Scoring won't be able to tell whether you're read an
> article or not, so it can't do its thing.

I think you mean "Yes" above.  Otherwise, it's not consistent with the
next sentence, which seems to confirm that my understanding was spot-on
:-).  Am I missing something?

>>   * [[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?
>
> Is it talking about adaptive scoring there?

I don't think so; at that point in the text it hasn't raised adaptive
scoring yet.  It's in the paragraph that begins, "Which one is better,
auto-expire or total-expire?"

>>   * 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)
>>     | 
>>     `----
>
> Yes, that seems rather excessive.

Any objections if I remove that passage in my patch?

>> * Suggestion: Rename `gnus-auto-expirable-newsgroups'
>>   `gnus-auto-expirable-groups' since, generally, auto-expire only
>>   applies to mail and not to nntp.
>
> Gnus has historically used "newsgroups" and "groups" as synonyms, and I
> think that boat has sailed a long time ago.

Yeah, but Emacs supports aliases.  Is there any reason not to make
things clearer for future generations?

>>   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?
>
> There have been many reports about nnimap and the Agent not playing
> nice with each other.  I have yet to delve into that morass.  But I
> will.  :-)

We, the morassed, are very grateful. :-)

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




  reply	other threads:[~2011-07-06 18:28 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
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 [this message]
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=m2vcvfxnyt.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).