Re: [Pan-users] Are kill-filed messages shown as non read messages?

[Duncan]

Bob posted on Tue, 10 Jul 2012 18:24:15 +0000 as excerpted:

> On Wed, 11 Jul 2012 02:54:33 +1000, Steven D'Aprano wrote:
> 
>> Bob wrote:
>>> On Wed, 11 Jul 2012 02:09:12 +1000, Steven D'Aprano wrote:
>>> 
>>>> Bob wrote:
>>>>> Was going through my groups this morning and noticed no recent
>>>>> activity in this group, so I marked all as read, and then marked all
>>>>> threads as read.
>>>>>
>>>>> I moved to another group to do the same, and noticed that I still
>>>>> had 58 messages marked as unread in the group I had just marked as
>>>>> all read.
>>>>
>>>> If they're kill-filed, they're hardly read, are they?
>>> 
>>> No, they aren't read, but they then should not show up if they are
>>> killed as they are not available for reading.

>> View:Header Pane menu, you will see the very last entry is "Match
>> scores of -9999 (ignored)".

> That helps greatly.

For people not using stale distributions' old pan, and I see in the 
headers you're upto date with "Sexual Chocolate" (0.139) but this was 
added in ... well I don't have pan's git repo checked out to build ATM so 
I can't check the changelog, but I'd say 0.136 or 0.137 or so...

What you're looking for is pan prefs, actions tab. =:^)

There you can configure pan for "automatic actions" based on score.  It's 
possible, for instance, to mark watched posts auto-download or auto-cache 
(depending on how you use pan, auto-download would be for binary users 
that download-and-save directly, auto-cache for text users and binary 
users that set big caches, download to cache, and /then/ go thru it), 
negative-scored posts to auto-mark-read, and ignored posts to auto-delete.

That nicely eliminates the ignored-posts-still-show-as-unread problem! 
=:^)

If the feature had been introduced with the pan rewrite (0.90) or when 
pan first got scoring (0.14.x or earlier), it may well have been enabled 
by default with actions and score-levels described above, as they do sort 
of make sense.  But as it's a relatively new feature introduced to an 
otherwise reasonably mature software product, that might have been an 
unwelcome surprise to upgraders who handled things differently, so the 
safe alternative was to leave all actions disabled by default, until 
enabled by the user at the level they wanted.  Of course that means some 
people don't realize it's there and end up doing manually what pan can 
handle for them automatically, but...


Meanwhile, long-time pan users are used to doing it as described upthread, 
set match on ignored as well, then where there's lots of ignored posts, 
unthread and sort by score so all ignored posts are grouped, then select 
and mark-read/delete as desired.

Another alternative, tho problematic for people like me that sometimes 
leave a few posts deliberately marked unread to come back to later, is to 
use the mark-group-read function, either manually, or set the pan 
preference to mark groups read on exit.  I suspect that's what a lot of 
folks do.  But there's a technical issue with this that occasionally 
catches people too.  When this option is used, pan marks read everything 
upto the current high-water-mark[1], so on servers where posts don't 
necessarily appear in assigned sequential number order, this can cause 
pan to miss the out-of-order-numbered posts that appear later.


So marking only the ones actually seen is the most reliable method, but 
before the automated-actions feature, it either had to be done manually, 
or the easier but less reliable method could be used, or I suppose some 
people just ignored the unread number.

So the automated-actions feature is really cool in this regard.  =:^)  
But it's still new and I'm not sure that many people use it yet, so it's 
possibly still buggy in corner-cases.  So if you use it and see it doing 
something you don't expect, please post.  It may be that your idea of 
what it should be doing doesn't match Heinrich's (he's the one that 
programmed it based on my description of the feature as discussed for 
years but never implemented) and/or mine, or it may be a bug.  But the 
only way to find out is to post a question about it if it happens, and 
see.


---
[1] In nntp, a server numbers posts in a group in sequence, and a group 
request will return the lowest unexpired number, called the low water 
mark, and highest assigned number, the high water mark, along with an 
/estimate/ of the number of posts available.  (Some may be spam-filtered 
or canceled after numbering so number available may be less than high 
minus low.)  But on systems where an intake server does the numbering 
before the posts are sent to the user-visible server, the posts may 
arrive in an order other than the sequential number order, thus the 
problem if a client assumes nothing else will come in below the current 
high-water-mark.

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