Re: [Pan-users] Making Pan behave like OE/Windows Mail

[Duncan]

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" <address@hidden>
>> 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