Re: some mail annoyances

[Rob Browning <rlb@cs.utexas.edu>]

(Having mail problems.  First try bounced.  Hope everyone doesn't get
 this twice.)

Lars Magne Ingebrigtsen <larsi@gnus.org> 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 <rlb@cs.utexas.edu> PGP=E80E0D04F521A094 532B97F5D64E3930