Re: Keeping cached (*) mail articles in the backend. Bad idea?

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

Kai.Grossjohann@CS.Uni-Dortmund.DE writes:

> Hm.  You can mark the article dormant (?) or ticked (!) -- both of
> these won't be expired.

Mostly I just thought that having cached mail articles stay in the
mail folder might be a bit more elegant, certainly a bit less
redundant, but I could imagine that this might add too much complexity
to the expire (and other) code.

> If you need one more article state than allowed by total-expire, I
> suggest that you use auto-expire instead.

I could, but of course that prevents me from being able to play with
adaptive scoring (at least that was my understanding).

I think we've probably talked about this before on (c.e.g.), so I
don't want to waste your time again, but the short version is that
after listening to some pretty convincing arguments on the newsgroup,
I came to the conclusion that total-expire would be quite a bit better
than my current arrangement.  Accordingly, I was trying to move in
that direction.

The (4) states I wanted were unread, urgent, read/archived,
read/needs-attention/but-not-urgent.  With total-expire you really get
only three permanent states.  Presuming I was going to use
total-expire, I realized I could get the fourth state by using
cached/read articles.  Unfortunately, that had the ugly side effect of
moving all those articles somewhere else.  Since I use grep and
friends on my nnml groups reasonably often, it would be awkward to
have to specify two directories in every command.

> Do you need more marks than this?  I think user-defined labels are
> still on the todo list (and have been there for a long time).

User defined labels sound really nice as long as you can either tell
Gnus what their expiry behavior should be.  I'd offer to try and do it
myself, but I'm not sure I have the time right now, and I'm not an
elisp whiz.  I have a lot more experience with scheme and common-lisp,
though if Gnus doesn't delve to deeply into elisp eccentricities, I
might be all right...

Anyway, thanks to all for a wonderful tool, only a fraction of which
I've had the opportunity to learn.

-- 
Rob Browning <rlb@cs.utexas.edu> PGP=E80E0D04F521A094 532B97F5D64E3930