From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/79360 Path: news.gmane.org!not-for-mail From: lee Newsgroups: gmane.emacs.gnus.general Subject: Re: Gnus Questions #1: Article Expiry Date: Mon, 04 Jul 2011 16:29:18 +0200 Organization: my virtual residence Message-ID: <87sjqm15mp.fsf@yun.yagibdah.de> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1309789836 12475 80.91.229.12 (4 Jul 2011 14:30:36 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 4 Jul 2011 14:30:36 +0000 (UTC) To: ding@gnus.org Original-X-From: ding-owner+M27656@lists.math.uh.edu Mon Jul 04 16:30:32 2011 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from util0.math.uh.edu ([129.7.128.18]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QdkAM-000307-Ob for ding-account@gmane.org; Mon, 04 Jul 2011 16:30:27 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by util0.math.uh.edu with smtp (Exim 4.63) (envelope-from ) id 1Qdk9O-0006V4-KK; Mon, 04 Jul 2011 09:29:26 -0500 Original-Received: from mx1.math.uh.edu ([129.7.128.32]) by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1Qdk9N-0006Uv-9v for ding@lists.math.uh.edu; Mon, 04 Jul 2011 09:29:25 -0500 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx1.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1Qdk9K-0008JQ-Ns for ding@lists.math.uh.edu; Mon, 04 Jul 2011 09:29:23 -0500 Original-Received: from static.103.179.46.78.clients.your-server.de ([78.46.179.103] helo=static.73.179.46.78.clients.your-server.de) by quimby.gnus.org with esmtp (Exim 4.72) (envelope-from ) id 1Qdk9I-0000ZO-AI for ding@gnus.org; Mon, 04 Jul 2011 16:29:20 +0200 Original-Received: from lee by yun.yagibdah.de with local (Exim 4.76) (envelope-from ) id 1Qdk9G-0000Xc-Ii for ding@gnus.org; Mon, 04 Jul 2011 16:29:18 +0200 Mail-Followup-To: ding@gnus.org In-Reply-To: (Dave Abrahams's message of "Sun, 03 Jul 2011 19:30:23 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) X-Spam-Score: 0.1 (/) X-Spam-Report: SpamAssassin (3.3.1 2010-03-16) analysis follows Bayesian score: 0.0000 Ham tokens: 0.000-1860--6068h-0s--0d--H*u:Emacs, 0.000-1726--5631h-0s--0d--H*u:Gnus, 0.000-1653--5394h-0s--0d--H*u:linux, 0.000-1653--5394h-0s--0d--H*UA:linux, 0.000-1602--5228h-0s--0d--H*u:gnu Spam tokens: 0.956-4256--1439h-52648s--0d--H*r:quimby.gnus.org, 0.925-244--194h-4048s--0d--H*r:sk:static., 0.894-23--41h-584s--0d--dormant, 0.883-1541--4186h-52947s--0d--HX-Spam-Relays-External:quimby.gnus.org, 0.883-1541--4186h-52947s--0d--H*RU:quimby.gnus.org Autolearn status: no -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 2.0 HELO_DYNAMIC_IPADDR Relay HELO'd using suspicious hostname (IP addr 1) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:79360 Archived-At: Dave Abrahams 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