[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Pan-users] cached articles marked as read?
From: |
Duncan |
Subject: |
Re: [Pan-users] cached articles marked as read? |
Date: |
Tue, 22 May 2012 07:27:51 +0000 (UTC) |
User-agent: |
Pan/0.138 (Der Gerät; GIT 169a3a7 /usr/src/portage/src/egit-src/pan2) |
Duncan posted on Tue, 22 May 2012 06:37:19 +0000 as excerpted:
> Vito 'ZeD' De Tullio posted on Mon, 21 May 2012 20:02:36 +0000 as
> excerpted:
>
>> I have a bad connection, and I want to automagically fetch all new
>> headers + body of the newsgroup I subscribed.
>>
>> I found at "Edit" -> "Edit preferences" -> "Actions" a way to cache new
>> articles, settings the value "Only new (score == 0)" at the third drop
>> down menu (labeled "Cache articles scoring at").
>>
>>
>> Unfortunately, I found that the messages are also marked as read! If I
>> do <shift>+a ("get new headers in subscribed news") I can see the
>> layout pane with some new messages, but if I select a newsgroup I found
>> no unread messages!
>>
>>
>> Is this intentional? Is a bug? Is there a "correct" way to cache all
>> new messages in all subscribed groups?
>
> This is quite new code, this year, and hasn't had a lot of testing yet.
[History deleted...]
OK, looking at the actions tab in preferences, I now see that the text
description isn't quite as clear as I envisioned. I'm not sure if the
functionality works the way I had envisioned, or more like it actually
states. As I said in the previous post, while I (re)described from and
old discussion what HM implemented, I've not actually tested it as I
haven't done binaries in years and text doesn't really need at least the
auto-cache/download as much.
The way it's /supposed/ to work, you tell me if it does...
The four actions work on scores (that much should be clear), with each
acting independently of the others, except of course that if a message is
deleted, that's obviously it, the other actions won't have a chance to
take place.
The two "negative" actions, delete and mark-read, are supposed to work on
messages scored AT OR BELOW the specified score category, while the two
positive actions, cache and download, should work with messages scored AT
OR ABOVE the specified score categories. The AT OR BELOW, AT OR ABOVE
bit isn't clear in the current interface, and as I've not tested, I
actually don't know if it works that way or not, but that's how it's
SUPPOSED to work.
So if you set CACHE articles scoring at... zero/new, then it should CACHE
articles scored above zero as well.
Does it?
Meanwhile...
You didn't specifically mention... what are the other three actions set
to? Are they all disabled, or do you have them set to a score category?
Obviously, the mark-read action is the one we're most interested in here,
but deleted would also have potential to interfere. Just making sure we
don't have unintended interference.
The general idea, meanwhile, was to allow something like this:
Automatically:
Delete messages scoring at or below: [-9999] (ignored)
Mark-read messages scoring at or below: [-1] (negative)
Cache messages scoring at or above: [0/new] (all not negatively scored)
Download attachments for messages scored at or above: [+9999] (watched)
But, by having the configuration available, people who wanted to could
disable all actions, or for instance set delete on anything negative,
auto-mark-read 0, leave +1 to +9998 alone, and auto-cache (for text) or
auto-save-attachments (for binaries) watched.
Of course, that would also allow someone to set both delete up thru +9998
and auto-save down thru zero, if they wanted, which obviously couldn't
work, as the messages in the overlap would be deleted before they could
be saved. But we trusted people to be smart enough not to do stuff like
that, except possibly for testing, to see that it would actually delete
before save and not crash or something.
Also, not directly related, but *IMPORTANT:*
Pan's cache is only 10 MB by default. For binary message caching, you
*WILL* need that larger. While that's a decent number of text messages,
if you're trying to cache binaries at all, that's TINY!
I routinely run a cache of several gigs for both my text and binary
instances (which I keep separate). On the text instance, I have messages
set to never expire, with a multi-gig cache (tho only a bit less than a
gig actually used) to ensure that my text message archive of several
years stays around.
Back when I ran binaries, I had an entire partition of some 12 gigs
dedicated to binary cache. My routine was to grab overviews/headers,
download a message here or there to get a sample, delete what I knew I
didn't want, and set the rest to download to cache. Then I'd go to work
or to sleep or whatever and come back later, when everything was cached
locally, to sort thru things and actually save them off somewhere, or
delete them. I remember when I first started with pan, being confused
because I had set it to download a bunch of stuff, but when I came back,
very little of it was still there, because the cache was only 10 MB and
it had deleted stuff as fast as it came in, after that!
By contrast, the original intent (from long before pan even had scoring)
was obviously to have people directly download and save off attachments.
For that, a 10 MB cache is generally sufficient, enough to decode and
save off the binary as it reaches completely cached, then delete the
individual message parts composing it to make room for the next one.
So, if you're caching binaries, be *SURE* you have pan's cache (first
page of prefs, behavior) set large enough for the binaries you want to
cache!
But if none of that's the problem I think I might know what is. Next
post...
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman