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 _______________________________________________ Pan-users mailing list Pan-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-users
