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