Re: [Pan-users] Kill-file: no "mark as read"?

[Duncan]

Graham Peter Davis posted on Thu, 21 Apr 2011 08:19:20 +0000 as excerpted:

> In other news-readers I've used, it's possible to "kill-file" someone by
> setting their postings to "mark as read". I can't find such a setting in
> Pan. Is there one?
> 
> I find the (seeming?) lack of this option irritating for two reasons:
> 
> (1) If I have Pan set to not display kill-filed postings, the news-group
> may indicate that there are a number of unread messages but have no
> headers displayed. My first reaction is that the database is somehow
> corrupted - a common problem I had with another popular newsreader whose
> name is withheld to protect the guilty - before I guess that it's due to
> kill-filed postings.
> 
> (2) If I set the display to show the kill-filed postings, clicking on
> "next unread article" will eventually land me on a kill-filed post. This
> rather defeats the object of the exercise.
> 
> If it isn't already there but I haven't seen it, could "mark as read" be
> added as an option? To be honest though, I don't see the point of not
> marking kill-filed postings as read so why not automatically mark all
> such postings as read?

A tri-fold feature including this as one of them has long been proposed 
as, finally, a replacement for old-pan's rules.

(Old-pan, in context, refers to the old C versions, 0.14.x and previous. 
New-pan refers to the C++ versions starting with 0.90.  FWIW, there's also 
old-old-pan, the gnome-1 version that lasted thru 0.11 (with 0.12 the 
beginning of the gtk-2 version known now as old-pan), that was around when 
I first switched to Linux and discovered pan in 2001, when MS pushed me 
off their platform with XPrivacy, crossing a line I wasn't going to 
cross).  There's hints of an even older version before that, before 
Charles Kerr took over from the original pan author, but I've /no/ idea 
what that was like, nor how smooth... or not... that transition was.  Of 
course, pan has just recently had yet another transition, from Charles 
Kerr as lead dev, he no longer regularly uses news and grew disinterested, 
to the PKovar/KHaley team...  What that'll bring, mild changes but no real 
big new features such as this, mainly keeping pan compiling and running 
against the latest libraries and built with the latest gcc, or a whole new 
pan era, I'm not sure even the two principles mentioned above really know.)

These "rules" as old-pan called them, were configured using a dialog sort 
of like the scoring dialog we have today, only they allowed ACTIONS, 
including auto-delete or mark-read on the one hand, and auto-download, on 
the other, based on various factors such as SCORES, age (for auto-
expiration, pan handles that normally, per-server, now), etc.

But it was always Charles' opinion that the rules setup was too obscure 
and hard to setup, for the ordinary user.  (It's no coincidence that pan 
was a gnome app, gnome seems to have this "disease" of trying to simplify 
everything into impotence, as well, at least from the perspective of many 
power users.  That's one reason I'm a kde user for most things, pan being 
one exception, but as mentioned above, it's gtk not full gnome now and 
hasn't been full gnome since gnome-1/pan-0.11 era.)

Unfortunately, in practice it seems he let the perfect be the enemy of the 
good, as while alternatives were discussed, none ever got implemented.  
That was the last big feature of old-pan that new-pan really lacked.  Even 
if the rules implementation was complex, it DID actually allow these 
automated actions to be configured.  Now, while expiration is handled by 
pan's normal code, the other actions, primarily auto-delete, auto-mark-
read, and auto-download, remain unimplemented.

Every so often I re-describe the way the GUI was supposed to work, in the 
hopes that someone with the coding ability (I'm not a coder, 
unfortunately, tho I understand enough of the lingo and principles to 
debug, sometimes predict whether a suggestion is easily codable or not, 
and in general act as a go-between) will be inspired and create a patch.  
I've not done so in awhile, so here it is again:

The idea was to have the three auto-* actions (delete/mark-read/download) 
integrate with the scoring categories pan already uses, as seen in the 
color preferences for the scoring column and in the view, headers, menu.

The configuration would probably be on a new preferences tab titled 
something like Automation, and would look something like this:

Automatically:

        Mark read posts scored less or equal to [category].

        Delete posts scored less than or equal to [category].

        Download posts scored more than or equal to [category].


        [x] Don't save auto-downloaded, simply cache them.


... where [category] indicates a dropdown box with the following entries 
(with or without the word-labels):

disabled                        (disabled)
ignored                 <=      -9999
negative        -9998   to      -1
normal/zero                     0
low-positive    +1      to      +4999
high            +5000   to      +9998
watched                 >=      +9999

Arguably, ignored should be marked-read or possibly even deleted by 
default.  If ignored is deleted by default, negative would be marked-read 
by default.  And watched would be auto-downloaded by default, of course.

The other position that could be argued is that of least surprise.  
Disable all three by default, and let the users set them if desired.  This 
would prevent pan's behavior from changing unexpectedly, for long-time-
users who upgrade to a new version with this feature.

The checkbox would allow users like me to only download-to-cache instead 
of using download-and-save, if desired.  (This could either remain a 
config-file-only option, no GUI, or added to the GUI along with a GUI 
option for setting cache size, the default is 10 MB, way too small for 
doing this with binaries, but the cache size option is only available by 
direct-editing the config file, presently, again, because Charles thought 
that was too complex an option to be appropriate for the GUI. <shrug>  As 
long as it's available via config file edit, not hard-coded, forcing one 
to patch the source to change it.)

But the above config would be both FAR simpler than the old rules config 
was, AND flexible enough to allow both the auto-download-everything 
extreme at the one end, and the auto-delete everything (arguably with the 
exception of watched, that one could be hard-disabled for the delete 
option) at the other, with quite the possible permutations in between.

It's quite possible that the internal implementation would actually use an 
individual numeric score (or the word disabled), instead of the category, 
and as such, be much like expiration in that if one edits the config files 
directly, one isn't limited to the arbitrary values allowed in the GUI.  
As with the expiration setting, this would serve the purpose of keeping 
the GUI quite simple, using the score categories theme already used in two 
other spots in the GUI, while allowing advanced users even more 
flexibility, should they so choose to edit the config files themselves.

But even if not, that's flexible /enough/ -- users can adjust their 
scoring if they need to, to hit the desired categories.

OK, that's explained.  But the other thing to consider is when such a 
thing might be implemented.

PKovar and KHaley are the devs (KHaley the lead dev in practice, PKovar 
the guy who deals with the Gnome side of things).  As is commonly said in 
FLOSS circles, "he who codes, decides".  As such, any new features and 
their timing is up to them.  (But being both AFAIK the senior guy on the 
list and most active, I believe my opinion ought to and /does/ carry 
/some/ weight, if only out of respect for half-insane old grandpa! =:^)

However, at least as discussed here, the recently released 0.134 should be 
a reasonably short "beta" release, with a stable release, possibly even a 
bump to 1.0, coming thereafter.  If they follow thru on that, adding 
features like this, even if someone actually does the coding (again, I'm 
not sure how active khaley intends to be, but someone else could create 
the patch and it'd almost certainly be applied reasonably quickly), won't 
occur until after the stable release.

However, a stable release and bump to 1.0 was discussed for some time 
before Charles grew disinterested and the code foundered for a few years.  
If it's going to do that again, yeah, get the code in there!  But of 
course, someone who has the ability must code it first, whether that be 
khaley, or someone else.  I wish I had that ability myself, but alas...  
Once the code is available, /then/ we can discuss whether we delay adding 
it until after a stable version, or not.  And some people might choose to 
add the patch to their own builds and test it out, regardless.

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