Gnus development mailing list
 help / color / mirror / Atom feed
From: Dan Christensen <jdc@uwo.ca>
To: ding@gnus.org
Subject: Re: Gnus Questions #1: Article Expiry
Date: Wed, 06 Jul 2011 16:00:16 -0400	[thread overview]
Message-ID: <874o2zrxgv.fsf@uwo.ca> (raw)
In-Reply-To: <m2vcvfxnyt.fsf@pluto.luannocracy.com>

Dave Abrahams <dave@boostpro.com> writes:

>>> * 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 far as I understand, the only difference between the two functions
is that the "now" version ignores the expiry-wait setting (i.e. it
assumes it is 0).

>> 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.

You are right, Lars was being brief.

>>>   * 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?

I think he meant "No".  It doesn't happen at expiry time, but when it
happens, it depends on how articles are marked.  

>>>   * [[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?"

It's definitely talking about auto-expire/total-expire, and that
paragraph is the reason I use auto-expire.  It lets me use the
read mark on an article without it being considered for deletion.

>>>   * 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?

I use the above settings and don't know any other way to accomplish it.
If you change auto-expire to nil, then an article will never
automatically get the expire mark when read.  The above changes mean
that when you read an unread message, it gets the expirable mark, but
when you read an already read message, it doesn't get marked expirable.
This seems like it should be the default:  if I have changed the 
expirable mark to a plain read mark once, it's because I don't want
the article to expire, so why would I want it to get marked expirable
when I re-read the article?  Data loss ensues...

Maybe it will help to clear your confusion about the last two issues to
emphasize that an article can be read or expirable, and it's easy to
switch an article between the two marks.

Dan




  parent reply	other threads:[~2011-07-06 20:00 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
2011-07-06 19:55     ` lee
2011-07-06 20:00     ` Dan Christensen [this message]
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=874o2zrxgv.fsf@uwo.ca \
    --to=jdc@uwo.ca \
    --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).