Re: [Pan-users] Quirks with ignored authors or posts

[Duncan]

Benjamin Esham posted on Sat, 16 Jul 2011 19:42:08 +0000 as excerpted:

> Pan has a built-in mechanism for ignoring an author, i.e. scoring all of
> their posts at -9999. I see two (related) problems with the current
> implementation: first, that the "blocked" posts are not actually marked
> as read,

This one's interesting.  Here's the situation.

Old-pan (the C version, thru 0.14.x) used to have a feature called rules, 
that could be setup to cause pan to perform various _actions_ based on 
various properties of a post, including not only scoring, but post size, 
age, etc.  These actions included auto-delete, auto-mark-read, and auto-
cache (download-to-cache, not save, tho save _might_ have been an option 
as well, IDR).

At the time, pan auto-expired posts based on when the server expired 
them, so paid servers would keep particularly text messages around for a 
long time, often six months to a year, if not more.  And of course 
there's servers like gmane.org (list2news servers, it's how I follow and 
reply to this list, among others) that function as archives and 
effectively /never/ expire posts (unless they have an x-no-archive header 
or first body line).  So one of the uses for an auto-delete rule was to 
allow a user to set their own expiration of messages, before they expired 
off the server.  Of course, new-pan (the C++ rewrite, starting with 0.90) 
has its own per-server expiration setting entirely separate from what a 
server's expiration policy may be, so that particular functionality has 
already been replaced.

But it also allowed a user to configure if they wished, as I did, for 
example, ignored messages to be auto-deleted, negative-scored but not 
ignored (-9998 to -1) to be auto-marked-read, and watched messages (I 
actually had it set to all messages for certain groups) to be auto-
downloaded.

That was great and it worked for its purpose! =:^)

But pan is a gnome-family application (required gnome for gnome-1, now 
only requires gtk, but bugzilla and the official git repo are still gnome 
hosted), and Charles (Kerr, for many years pan's lead/primary developer, 
since before I first became active with it in 2002), arguably 
unfortunately, had a bit of the gnome "don't confuse the dumb users with 
too many config options, they're too stupid to cope with them" idea, and 
rules as they were then implemented were rather complicated to setup.  In 
fact, one of the more frequent FAQs on this list back then was how to set 
them up to do <whatever action>, so indeed, it WAS complex enough that a 
certain segment of the pan userbase couldn't figure it out without help, 
so in that regard, it WAS arguably "too complicated".

So then the pan rewrite came, and Charles dropped a lot of features that 
old-pan had.  His idea was to only re-implement what people actually used 
enough to request.

Well, over time, pretty much all the old features EXCEPT RULES were re-
implemented, and of course new-pan had some pretty nifty new features as 
well, including fully transparent multi-server handling (with old-pan, 
you worked with one server at a time, you could setup downloads from 
multiple servers, but only by switching to the other servers one at a 
time and setting up downloads from each of them separately, tho pan /was/ 
smart enough not to download a message that was already in cache).  Also 
quite significantly, new-pan's memory scaling was *MUCH* better --
old-pan would choke when a group had more than a couple-hundred-thousand-
headers pretty much no matter *HOW* much memory you had, while new-pan 
works well with groups that have millions of headers -- if you have the 
memory.

But despite over a year of VERY heavy development (new pan beta versions 
nearly every week, pan went from 0.90 to 0.132 in less than a year and a 
half, so in about 70 weeks there were 42 releases!), and all the OTHER 
features being either re-implemented or replaced with alternative 
functionality doing the same thing, rules were not on the list.

At some point, it became apparent that they weren't happening, and there 
was a discussion as to why.  Charles explained that he thought basically 
what I said above, that the rules functionality as it was, was too 
complex and confusing for users (and given the times I or others had 
explained it, we couldn't really disagree), that one of the prime 
functions, expiration control, had been solved differently, and that he 
was looking for a simpler setup, but hadn't come up with one yet.

So then a discussion took place.  What the list regulars seemed to think 
would work, and Charles seemed to agree, tho somehow it never got 
implemented, was something like this:

* The new feature would be called _Actions_, and a new Actions tab would 
be added to pan's preference dialog to configure them.

* Since the scoring mechanism already allowed /scoring/ based on nearly 
all of the old rules factors, we'd implement actions based on scoring 
only, thus simplifying things.

* Further simplifying things, we'd use the same scoring zones that pan 
already uses for score-column color-coding and that the view menu has as 
matching options for the header-pane, ignored (<=-9999), low/negative 
(-9998 to -1), zero/normal (0), medium (+1 to +4999), high (+5000 to 
+9998), and watched (>=+9999).

* There would be three or four actions (with #3 depending on whether the 
cache size was user settable or not), auto-

** -delete

** -mark-read

** -download (to cache)

** -download-and-save (attachments).



The tab could then look something like this,
taking the idea from how the scoring UI works:

(As a tooltip:  Here you can configure pan to take certain
actions on your behalf automatically, based on a post's score.)

--------------------8><------------------

Autommatically:

Delete          posts scoring at or below       [dropdown menu]

Mark-read       posts scoring at or below       [dropdown menu]

Cache           posts scoring at least          [dropdown menu]

Save            attachments scoring at least    [dropdown menu]

--------------------><8------------------

The dropdown menu would then look like this:

(Disabled)
<=-9999         (Ignored)
-9998 to -1     (Low)
0               (Normal)
+1 to +4999     (Medium)
+5000 to +9998  (High)
>=+9999         (Watched)


Everybody, including Charles I believe, thought something like that was 
*MUCH* simpler than rules had been, and that it would be a good 
replacement for rules.

But, by the time this discussion happened, Charles was getting burned 
out, as it was probably about 10 months into his coding streak.  I guess 
the thought of coding that last major feature was more than he could 
handle at the time, but for that or whatever other reason, it didn't 
happen.

At about 16 months after 0.90 was released, Charles pretty much quit 
working on pan at all.

He had /always/ been someone who coded in fits and spurts.  He'd go great 
guns for awhile, then stop for some months, then go at it again.  Before 
the C++ rewrite, he had, seemingly, dropped off the face of the earth for 
over a year and a half, and hadn't done much for another year before 
that.  But then out of nowhere it seemed, he posted to the list saying he 
had a surprise coming up in a few weeks.  That surprise was the 0.90 C++ 
rewrite, released on April 1st, 2006 (the web site has it as April 2nd, 
but AFAIK it was the first, because it corresponded with April Fool's 
Day).  I remember the day well because it was April Fool's Day, but the 
year, and the dates below, are from pan's home page.

Then as I said, he went great guns for over a year, until about 0.131, 
with 0.132 coming out spaced a bit further toward the end, 16 months to 
the day after 0.90, on August 1, 2007.

Then he dropped off the face of the earth for another year, exactly.  
0.133, with only some minor maintenance updates and bugfixes, PLUS a 
security patch (which had all been submitted as patches by the various 
distros, etc), appeared exactly a year after that, on August 1, 2008.

After 0.133, off the face of the earth, again.  Sometime later, probably 
late 2009 or early 2010, Charles posted that he was no longer doing 
newsgroups regularly and if anyone was interested in taking over pan 
maintainership, drop him a line.  Charles' time as pan's head developer 
was over.

Some months later, KHaley became the new _unofficial_ pan head 
developer.  He (well, the handle's gender neutral but AFAIK traditionally 
in English, "he" has been used in singular person of unknown gender 
contexts, while "she" is most common AFAIK for personification of 
inanimate objects such as ships and hurricanes... until political 
correctness came along and turned that on its head) had cloned the 
official Gnome pan git repo to github (using the name "lostcoder" there), 
and began integrating various community patches that had been floating 
around, as well as making at first relatively small tweaks of his own, 
fixing bugs, etc.

That began pan's new era.

But KHaley for reasons never made public (it's a mystery to me, too) 
isn't interested in working with Gnome.  Whatever.  He stepped forward 
with the necessary developer skills (which BTW I don't have, I wish I 
did...) when pan was otherwise abandoned, and quickly became the defacto 
if unofficial lead dev, when there was no one else doing it.  But no 
gnome access meant no official releases so for some further months, 
people, mostly regulars to this list (group, as I use it on gmane) who 
wanted to use current sources, had to install git and pull from KHaley's 
repo on github, then build it themselves (tho a couple people have 
stepped up with binaries for MS Windows users, etc).

Around late December of last year, IIRC, Petr Kovar stepped up.  He's a 
gnome translator so already had an official gnome account, but AFAIK, not 
a coder.  However, his gnome git account access but no coding meshed very 
nicely with KHaley's coding but no interest in an official gnome git 
account, and the PKovar/KHaley team together are now the official gnome 
repo pan maintainers.  They contacted Charles, who was very happy someone 
was finally leading pan forward again, and thus happy to give his 
blessing, and worked out maintainer access to pan's home page at 
pan.rebelbase.com, as well. =:^)

KHaley created an upstream/release branch, and PKovar began pulling from 
it and committing to the official gnome repo.  On February 15, 2011, the 
first PKovar/KHaley release was announced, version 0.134, again 
containing mostly accumulated bugfixes and minor maintenance patches (to 
keep it working against current libraries and building with current gcc, 
for instance), but with a few very minor functionality tweaks.

That was the first /release/ of pan's new era. =:^)

There has been one release since then, 0.135, on June 5.  This one had a 
few more minor features, but they're still feeling their way, so nothing 
major yet.

But there is one more recent development.  I'm not actually sure on which 
side of that June 5 release it happened, but Heinrich Mueller has a pan 
git clone on github as well, and is presently working on another very 
often requested feature that somehow, Charles never got around to in the 
decade or so he worked on pan (tho there was one beta with a non-
functional GUI for it, back in the C version era, quickly pulled by the 
next beta when I guess he decided he wasn't satisfied with it), binary 
posting. =:^)  

There's still some warts in that, so it'll be awhile before that gets 
pulled into khaley's stable branch for PKovar to pull for an official 
release, but the *IMPORTANT* thing is that THIS IS THE FIRST MAJOR PAN 
FEATURE ADDITION IN **YEARS**, since 2007 *AT* *LEAST*!!  There's further 
important implications as well, since it means that for the first time 
since, AFAIK/IIRC, Chris Lambin, back in the C pan era, so 2004 or 
earlier, there's two developers taking a very active interest in pan.  
And even back then, I don't remember Chris being active on the list, so 
really, this is the first time since I became active on the pan lists 
back in 2002, that there have been two very real active pan developers on 
the list!

That actually makes four people heavily involved in the pan project, 
KHaley and HMueller as devs, PKovar as official repository and web site 
maintainer, and me on the lists, doing what I can since I can't code and 
don't have gnome access.  Plus there's a number of other people with some 
involvement on the lists, doing windows ports, submitting occasional 
patches, etc.  It's very possible that's more people both heavily pan 
project involved and with some lessor but still contributory involvement, 
then ever before in pan's history!

PAN HISTORY IS BEING MADE!

And here news is supposed to be dying!

OK, so I know that doesn't really address when or even really if this 
feature will ever make it.  But we have active developers now, while for 
quite some time pan looked to be a lumbering zombie, dead, but still 
carried until the few remaining users lost interest and went away, or 
until it would no longer compile on a modern distro, with no upstream, so 
the distros eventually abandoning patching it to try to keep it working, 
as well.

That's a **HUGE** difference from just a year ago.  It's hard to say what 
the future will bring, but it's certainly looking much brighter than it 
was back then!

And because this feature is a popular request (in some form or another, 
you want auto-mark-as-read, others want auto-save, I, noting that while 
the GUI doesn't have a setting for it because Charles didn't think one 
was needed, it's possible to set pan's cache size by directly editing the 
config file, would like auto-download-to-cache) *AND* has a reasonable 
configuration GUI already discussed and worked out, even tho neither of 
the currently active developers have specifically said anything about it, 
I'd say there's a reasonable chance it'll make it in eventually... for 
purposes of argument, say perhaps a year to make it into a git version 
for testing, maybe two to get it tested, the bugs worked out, and an 
official release with the feature.

Of course, if someone having the skills is sufficiently interested to 
create the patch, either KHaley or HMueller are very likely to 
incorporate it into their versions right away.  All it takes is getting 
someone sufficiently interested in it that has the skills to create and 
submit the patch!

Which, really, was all it would have taken back when we were discussing 
it in the Charles era, as well, but somehow it didn't happen.  But while 
I'm NOT a coder and thus can't make promises, given all the current 
activity, I'd say the chances of it happening within the two years I 
suggested for purposes of argument, is higher than it has ever been 
before. =:^)

And, your posting and my explanation of the proposed feature and config 
GUI could well get either one of them, or someone else, interested.  So 
together, we just increased the odds ourselves, even if neither of us can 
ourselves code it up.  =:^)  (I assume you can't, if you can, by all 
means...!)

> [...] and second, that replies to a blocked post are still shown.
> 
> The second issue is a little more serious, since in Pan's display it
> looks like replies to blocked posts are actually replies to the blocked
> post's parent. This could be taken care of by automatically ignoring the
> subthread started by any post with a score of -9999. (If I've specified
> that I *never* want to read posts by a certain user, you can bet that I
> don't want to read the replies to those posts either.)

Well, they /are/ in the downline thread of the blocked-post's parent, so 
the threading part is correct, given the blocked post isn't appearing.

Meanwhile, you /do/ know about the subthread-scoring feature, right?


Here, mainly because pan cannot auto-delete ignored and auto-mark-read 
low-scored posts, I choose NOT to actually hide these posts.  Instead, I 
make it a point to:

* Ensure that the score column is visible in the header pane.

* Have pan's color config setup so the score categories are clearly color-
identified, so I can see them in the score column as set in the first 
point.

* Set my view to match all scores (view menu, header pane flyout, bottom 
section).

This way, all posts are visible but I can immediately identify low-scored 
and ignored posts, deleting or marking-read as desired.

I generally do NOT want replies to ignored posts similarly ignored here, 
as in the groups I follow, the replies are often witty or insightful, and 
therefore continue to be of value to me.  As a result, I do NOT use 
ignore subthread functionality much if at all.  However, with the above 
setup, since you can immediately ID ignore-scored (base on author, etc) 
posts, you can take that opportunity to ignore-score the entire subthread, 
if you wish.

Another tip:  Depending on the group, for instance, where most of the 
ignore-scored posts are spam and there's enough of it to warrant the 
effort, I'll often unthread (I have a hotkey, alt-T, assigned to 
threading-toggle, so I can hit that instead of having to go thru the 
menu), click the label on the score column to sort by score, select the 
now nicely contiguous group of ignored posts, and delete.

You could try modifications of the same thing, tho unfortunately it's not 
possible to work with scores efficiently on a multiple selection like 
that, so scoring the subthread would have to be done one at a time.  And 
once the subthreads are ignored as well, you'd have a problem as each 
ignored subthread with active posts would create that many more to one-at-
a-time process the next time.

But wait.  I think I figured out something that should work.  For all 
ignored, use subthread scoring NOT to mark them ignored, but to set them 
to say -9998.  Then they'll sort right next to the ignored ones, while 
showing up color-coded as low-scored instead.  You can then use subthread-
scoring on all the new ignored, then mark-read or delete both the ignored 
and the -9998-scored subthreads right next to them.

Once the ignored posts (and almost ignored subthreads) are dealt with, 
hit the threading toggle again and go about your business.  You may want 
to click on the group again to "reenter" it, thus forcing a refresh and 
hiding any just-marked-read messages (assuming you have match only unread 
on), as well as forcing pan to store the current group state to disk so 
if it crashes, you don't have to redo it.  Of course, this works best if 
you don't have pan set to download new headers on group entry, because if 
you do, the reenter will trigger that, possibly bringing in new ignored 
articles to mark.  (FWIW, I have both the download new headers when pan 
starts and download new headers when entering a group options off, here.  
If I want new headers downloaded, I can hit the button or hotkey to 
download them.)

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