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
next prev parent 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).