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