David WE Roberts posted on Sat, 26 Jan 2013 17:42:30 +0000 as excerpted: > On Sat, 26 Jan 2013 16:51:12 +0000, David WE Roberts wrote: > >> Now fixed email address (I hope). >> "David WE Roberts" <nos...@btinternet.com> >> wrote in message news:... >>>I asked this question elsewhere and was directed here.
This would be the place. =:^) >>> I can see that I can watch threads, and also (with a bit of >>> investigation) write a rule so that I watch any thread I start. >>> >>> What I would then like to do is sort the header pane so that all the >>> watched threads are at the top and threaded, and then the rest of the >>> unwatched threads are displayed with the default behaviour i.e. >>> threaded and displayed in date order of start of thread. >>> >>> However in Pan if I sort on score I see the watched threads at the top >>> but then the other posts unthreaded below in date order of posting (I >>> think). Seems you figured out the threaded thing below, but FWIW, pan has a toggle for threaded or unthreaded. There's no threading only half the posts. >>> Running Pan on various Windows PCs and under Ubuntu as well. One >>> version is Pan 0.133 on Windows Vista 32 bit. FWIW, 0.133 is now rather old. I'm not sure how much you know about pan history, but Charles Kerr was the lead dev for many years, then eventually lost interest as he apparently doesn't do news any longer. He repeatedly asked for volunteers willing to take over, but they didn't appear right away, so for some years, pan pretty much stagnated. IIRC 0.133 was the last Charles Kerr release, a maintenance release integrating a security fix and a few patches to keep pan building with current gcc against current libs, but not much else. So even when it was released, little had changed even then for several years. 0.133 was released on August 1, 2008. Then khaley picked things up, at least to the point of integrating distribution and other patches that had been floating around in the community, to keep pan building with current versions of gcc and various libraries. He did some limited new code, but his main emphasis was integration of patches from others. That was a very valuable contribution as pan was getting stale, but khaley was a dev only, not interested in the bureaucratic side of things, so he didn't formally take over and never did any releases. People who wanted current pan pulled sources from his git repo during that period. Then Peter Kovar, already a gnome translator but not primarily a dev as such, joined the team. He complimented khaley very nicely as he was able to take the work from the khaley pan git repo and finally do public releases again, the first of which was 0.134, integrating the release- ready bits from two and a half years of khaley's work. 0.134 was released in mid February, 2011. Later that year, 0.135 was released with further updates, in early June, 2011. Last year was a BIG year for pan in large part due to Heinrich Mueller joining the team. 0.136 thru 0.139 were all released in quick succession between early April and late June, 2012. They brought a lot of new features, many of which had been on the wishlist for YEARS, including binary posting, full native SSL/TLS support, pgp handling, and a plethora of new options supporting the above as well as various new minor features. Most of these changes are due to Heinrich's fresh look at the code and willingness to just get in there and do it. Apparently the timing was good too, as he got a lot done in just a few months. Then the second half of the year he apparently got busy with "real life" again, and little more has been done. However, those of us regularly building and running pan from the main gnome git repo know that there was a bit of activity again in December, so with a bit of luck, the coming months will bring further pan improvements and a release or two. =:^) All that basically to say, 0.133 is 2008 vintage, rather dated at this point. I'd definitely recommend grabbing at least 0.134, to get at least that first set of post-Kerr-era bugfixes and improvements. 0.135 would be better, 0.136 would bring you to within the year, and of course 0.139 would be current release. But of course building pan on MS is much more difficult. However, if you look, I believe it's Steve Davies that keeps a reasonably current (32- bit) pan build around for MS. Actually, yes. I see it even linked from the pan site, http://pan.rebelbase.com =:^) Looks like his "stable" build is 0.135.207, from October, 2011, and he has several experimental builds up thru 0.139.211 on Sept 19, 2012. > One penny has just dropped. > > If the score is negative (-100) or positive (9999) if you sort on score > the scored article always aligns with the oldest posts and articles. > > So if you have the 9999 at the top of the header pane you get the oldest > threads next (which tend to look unthreaded because most posts have > timed out). > > So what I think I need is for sorting by score to have the positive > scores first (date within score, newest first), then the null scores in > recent date order, then the negative scores (again newest first). > > I'm struggling with the logic of aligning both positive and negative > scores with the oldest threads. AFAIK, what's actually going on here is "secondary" ordering. When you click a column to sort by it, pan does so, but for articles/threads at the same ordering rank, the sort should be the same as whatever the previous sort order was. So if you click on the date column and then the score column, pan will sort by score, but for everything at the same score, pan will order by date, since it was the last used sort order before score. And of course, clicking on a current-sort column reverses the sort order. That's the way these sort order things normally work anyway. All my current pan usage is for text groups which I almost always keep date sorted, so I've not had occasion to actually note it in awhile, but back when I did binaries, I changed sort much more frequently, and that's the way it worked then. But I don't know that there's a way to keep primary sort and secondary sort orders separate in regard to direction. AFAIK, changing direction will change it for both primary and secondary sort order, and they'll always both be the same direction. As for timing out, pan expires based on the settings you have for the server the post was downloaded from. Unlike old pan (0.14.x, pre- rewrite, that code's nearing a decade old now, just checked the website and it's actually 9 years to the month, January 2004 for the last in the series 0.14.2.91) and some other news clients which expire posts when the server does, with pan, expiration is totally under your control. Of course you aren't going to be able to actually download posts that have expired from the server if you don't already have them cached, but cache size is configurable as well, so it's possible to do what I've done with my old ISP newsgroups, and effectively archive groups and posts even after the servers they were posted on have ceased to exist! (Tho do note that pan loads and rethreads all posts at startup, so startup can take longer if you do this. However, defragging the pan dir, or backing up the pan dir elsewhere, deleting the working copy, and copying them back from backup, should dramatically reduce pan load time with such long-time- archived posts.) Thus, you could actually set a longer (or unexpiring) expiration and then manually delete threads before they reach it, so as to avoid the stragglies effect you mention. Of course, hiding marked-read posts can simplify the display as well, but results in similar stragglies, so it's upto you. FWIW for text groups (which I don't expire), I hide marked read by default, but I have a hotkey (r) configured to toggle the setting, so I can quickly get the whole- thread-view if I want/need it. For binaries (which I handled in a separate pan session using the PAN_HOME environmental variable to point to a different dir than the textgroup session pointed to, and had a dedicated partition of a specific size for cache, so it couldn't infringe on my regular storage area), I didn't do automatic expire either, but I deleted when I was done, thus keeping only a fairly short working timeframe around. Whether I hid marked-read or not with binaries thus depended on what I was doing, since I simply deleted when I was done, whereas with text, marked-read signified that I was done. Hope that's of /some/ help, anyway. -- 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
