From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/24520 Path: main.gmane.org!not-for-mail From: Rob Browning Newsgroups: gmane.emacs.gnus.general Subject: Re: some mail annoyances Date: 28 Jul 1999 02:36:30 -0500 Sender: owner-ding@hpc.uh.edu Message-ID: <87so696xa9.fsf@raven.localnet> References: NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1035162074 9193 80.91.224.250 (21 Oct 2002 01:01:14 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 21 Oct 2002 01:01:14 +0000 (UTC) Return-Path: Original-Received: from farabi.math.uh.edu (farabi.math.uh.edu [129.7.128.57]) by sclp3.sclp.com (8.8.5/8.8.5) with ESMTP id DAA26255 for ; Wed, 28 Jul 1999 03:38:33 -0400 (EDT) Original-Received: from sina.hpc.uh.edu (lists@Sina.HPC.UH.EDU [129.7.3.5]) by farabi.math.uh.edu (8.9.3/8.9.3) with ESMTP id CAB06720; Wed, 28 Jul 1999 02:37:56 -0500 (CDT) Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Wed, 28 Jul 1999 02:38:04 -0500 (CDT) Original-Received: from sclp3.sclp.com (root@sclp3.sclp.com [204.252.123.139]) by sina.hpc.uh.edu (8.9.3/8.9.3) with ESMTP id CAA00116 for ; Wed, 28 Jul 1999 02:37:45 -0500 (CDT) Original-Received: from cs2868-35.austin.rr.com (mail@cs2868-35.austin.rr.com [24.28.68.35]) by sclp3.sclp.com (8.8.5/8.8.5) with ESMTP id DAA26234 for ; Wed, 28 Jul 1999 03:36:34 -0400 (EDT) Original-Received: from raven.localnet ([192.168.1.7] ident=mail) by cs2868-35.austin.rr.com with esmtp (Exim 3.02 #1 (Debian)) for ding@gnus.org id 119OGN-0000c4-00; Wed, 28 Jul 1999 02:36:31 -0500 Original-Received: from rlb by raven.localnet with local (Exim 3.02 #1 (Debian)) id 119OGN-0000ic-00 for ; Wed, 28 Jul 1999 02:36:31 -0500 Original-To: ding@gnus.org Original-Lines: 172 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) Emacs/20.3 Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:24520 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:24520 (Having mail problems. First try bounced. Hope everyone doesn't get this twice.) Lars Magne Ingebrigtsen writes: > Gnus, by default, handles all its group using the same approach. (A while back, I started this elaboration to your post and then forgot about it. Now that I've come across it again, I don't really have time ATM to polish it up properly, but perhaps it's got some merit as is. I don't know if you'll find it useful, and perhaps it should go in some other section of the docs, but I thought it might help the new but somewhat clueful user understand what's going on with mail expiry so that they'll be better equipped to decide how they'd like to handle their own mail. Feel free to correct any errors. This was drawn from my current understanding of mail article disposition, but I very well may have it wrong... Oh, and I'm missing a few useful cross-references in here, and I need the code snippet at the bottom that explains how to get Gnus to "re-mark" read articles to dormant (or whatever) just after you read them.) Gnus, by default, wants to handle all its groups, both mail and news, using the same approach. This approach is very newsreaderly --- when you enter a group, you will see any new or unread messages. Whenever you read a message, it will get marked as read, and you won't see it again unless you explicitly ask for it. You will also always see any messages that you have marked as ticked (!), and any message you marked as dormant, but you'll only see the dormant ones if and only if it has unread or ticked followup articles. This explains what you can expect to *see*, but this tells you nothing about one of the more important issues when using Gnus for mail, that of article lifetimes, of determining when your articles be deleted forever. For news groups, message "deletion" (or expiry) is handled by the news server. After some period of time, older messages are just gone, so if you want to keep some of them around, you better do something about it (*note Persistent Articles::.). Until messages are expired (deleted) by the server, you can always ask to see them again. With mail articles, it's more complex. Mail articles are stored locally, on your machine, so it's up to you to decide how articles might eventually meet their demise. Which options you want will depend on your own personal habits, and perhaps more importantly, on how you think about the content of a given mail group; is it this a group where you want to keep most of the articles, or one you just skim for the high points and don't care too much about older content? As usual, Gnus gives you plenty of rope to hang... ahem, uh, rather a plethora of options for handling the situation. First it's important to note how the non-scoring marks interact with mail article disposition. Ticked, dormant, and unread articles will never be deleted through an automatic process. It's only the read (and expired -- more later) articles that you have to be concerned with. Further, if you mark any mail articles as persistent, even though the actual mail group article might be deleted through the mechanisms described below, the cached copy will still be available. So how does Gnus decide which articles to delete? Gnus makes the decision based on the article's non-scoring marks and its age. From the perspective of mail article expiry (deletion) purposes, there are three main types of mail groups, total-expirable ones, auto-expirable ones, and "manually-expirable" ones. In total-expirable groups, any read articles will eventually be deleted. Since Gnus, by default, marks articles you've looked at as "read", this means that most articles in total-expirable groups will eventually be deleted unless you intervene and change the article's mark. When the deletion happens is controlled by the setting of expiry-wait. To keep an article from being deleted, you have to make sure it's marked as either ticked, dormant, or unread. Gnus scans total-expirable groups when they are exited for all read articles that match the current expiration criterion; matching articles are deleted. For large groups, this can be expensive, so you may want to use demon-expiry --- it's quite slick. Also, total-expirable groups are the only ones that will let you play with all of Gnus' scoring related bells and whistles. In particular, this is the only group type for which adaptive scoring works because it's the only one that doesn't rely on the expirable mark ('E'). (Marking an article as expirable messes up adaptive scoring because Gnus can no longer determine the difference between read and deleted articles (is that the right explanation?)). In auto-expirable and manually-expirable groups, read articles are never automatically deleted, only articles explicitly marked expirable (articles that have, one way or another, been given the 'E' mark), will be deleted according to expiry-wait. The difference between auto-expirable and manually-expirable groups is in how the articles get marked as expired. In auto-expirable groups, any article you read is automatically switched (just after you read it) from "read" to expirable (i.e. the mark changes from 'r' or 'R' to 'E'), so the default for articles you look at, if you do nothing else to them, is for them end up marked expired ('E'). In manually-expirable groups, no article is ever marked as expirable unless you specifically expire it. To summarize, the main difference between total-expirable groups and the other two is that total-expirable groups actually allow all of Gnus' fancy scoring stuff (specifically adaptive scoring) to work right, but you can't expect read articles to stick around like you can in manually-expirable or auto-expirable groups. The main difference between manually and auto expirable groups is how articles get marked as expirable. For completeness, I'll also mention that if you really want to power-nuke a particular message right this second, then you can do that with 'B del'. This command tells the group backend to do whatever it takes to banish the offending message to never-never land *right now*. This really isn't the best way to handle deleting your mail, but it's there if you really really want/need it. The one other issue relevant to mail article deletion is what mark mail articles are given just after you look at them. Normally, this is 'R', or the "read" mark, but you might want to change that to better accomodate the expiration behavior you've chosen when considered in the context of the particular mail group in question. If you choose total-expire for a group, then the default of marking a read article with an 'R' means that it's scheduled for expiration. In groups where you normally delete most of the articles, this might be exactly what you want, but if it's a group where you normally want to keep all the articles, having to go back and re-mark each article as dormant just after you read it can be a pain. Accordingly, you can tell Gnus to change the default mark that an articles end up with just after you read them. To do that, just use something like this: (Need code here, but I forgot what the proper bit of magic was...) > What many Gnus users find, after using it a while for both news and > mail, is that the transport becomes more and more irrelevant. What > becomes important is the size of the receiving audience. > > Many people subscribe to several mailing lists. These are > transported via SMTP, and are therefore mail. Some people have local > news groups which have only a handful of readers. These are > transported via NNTP, and are therefore news. > > The important distinction turns out to be not the transport > mechanism, but whether the messages are "personal" or "public". Many > users then subtly alter the behavior of Gnus according to these two > categories. > > Some users never get comfortable using the Gnus (ahem) paradigm and > wish that Gnus should grow up and be a male, er, mail reader. It is > possible to whip Gnus into a more mailreaderly being, but, as said > before, it's not easy. People who prefer proper mail readers should > try VM instead, which is an excellent, and proper, mail reader. > > I don't mean to scare anybody off, but I want to make it clear that > you may be required to learn a new way of thinking about messages. > After you've been subjected to The Gnus Way, you will come to love it. > I can guarantee it. (At least the guy who sold me the Emacs Subliminal > Brain-Washing Functions that I've put into Gnus did guarantee it. You > Will Be Assimilated. You Love Gnus. You Love The Gnus Mail Way. You > Do.) > > > -- > (domestic pets only, the antidote for overdose, milk.) > larsi@gnus.org * Lars Magne Ingebrigtsen > > -- Rob Browning PGP=E80E0D04F521A094 532B97F5D64E3930