[Pan-users] Re: How to quickly get article counts?

[Duncan]

Chris <address@hidden> posted
address@hidden, excerpted
below, on  Tue, 27 Mar 2007 12:31:45 -0400:

> I'm relatively new to this newly rewritten version of Pan as I have been
> using the stable version until a couple of days ago.
> 
> In the old version I could select a bunch of groups and refresh the
> article counts to give me an idea of which groups are real (ie. used)
> and which are not.  I can't figure out how to do this in the latest
> version (0.125 here).  I have to select each group and start downloading
> the headers to even begin to determine the activity level in the group. 
> This is a very tedious process when there may be 5 or 10 similarly named
> groups but only one of them is active.
> 
> Did I miss something?  I can't figure out how to get the raw article
> counts of a bunch of groups real quick like the old version?

What you want is the oft requested multi-group select feature back.  
Charles says it's not trivial to code, but given the popularity of the 
request, he has said he plans on doing it.  Still, I believe that's going 
to be after 1.0, which was to have happened as early as August of last 
year, but there turned out to be quite a few more real bugs to work out 
than anticipated, I guess.  That said, I've been expecting it for awhile 
(I was initially saying by year end for last year, when Charles said he 
couldn't imagine what would keep it past August... I guess we were both 
wrong), but Charles naturally wants the big 1.0 to be as bug-free as 
possible.

Meanwhile, there's a workaround, tho it's not as easy as one might like.

The first thing to realize is that subscribed or not, any time you do 
anything in a group, even just update article counts, pan creates file 
records for it that aren't automatically deleted.  If you still have your 
old pan config around and weren't deleting these things manually, check 
it.  You should see what I mean.  Thus, simply checking groups this way 
isn't and never has been quite ideal, in that even if you never revisit 
it or check it again, there's that record still around cluttering things 
up.

A second thing to realize is that new-pan honors the $PAN_HOME 
environmental variable.  While the default is ~/.pan2, setting and 
exporting that variable in the environment pan will use before starting 
it causes pan to use the new pan config dir pointed to by that variable.

The third thing to realize is that while this was originally done to 
allow users to change the location of pan's config, it ALSO makes it 
practical to run multiple pan instances, each with its own separate 
config.  Since another issue with new-pan is that all groups from 
multiple servers get lumped together in the same list, with no 
possibility of organizing it by group type or subject, and this multiple 
pan instance thing gives one the ability to work around that as well, I'm 
actually running two separate pan instances, complete with their separate 
configs, one for my text groups, one for my binary groups.

Actually, I'm running three pan instances, however, the third one being a 
"test" instance.  This overcomes the first problem mentioned above, that 
of having the record of all those groups only visited once stick around 
virtually forever.  I don't add a group to either my text or binary pan 
instances until I'm sure I want to keep it around for awhile.  I do all 
my testing in my test instance, where it's easy to clean things up 
without losing the records for groups I regularly participate in.

So... what you may want to do is create a similar "test" pan instance.  
When you want to check out a bunch of groups, go to your test instance, 
subscribe to all the groups, and hit the update headers for subscribed 
groups button.  When you are done looking around and have decided which 
groups you want to really subscribe to, subscribe to only those in your 
regular pan instance, and blow away the records for your test instance, 
so it'll be fresh and ready to go the next time you want to test 
something out.

Here are some additional notes on making multiple instances work.  For 
config files that you want to share between instances, symlinks work 
well.  I have a "global" settings dir that contains all such files 
(including my scorefile and accels.txt, among others), and just symlink 
them from the individual pan instance config dirs as necessary.  For 
launching the various pan instances, I use little shell scripts, pan.bin, 
pan.text, pan.test, etc, that set and export $PAN_HOME and do a bit of 
additional trivial housekeeping.  Then, instead of having a single pan 
desktop menu entry point at the pan binary itself, I have several of 
them, pan.bin etc, pointed at the appropriate shell script starter.  (KDE 
is my desktop environment of choice, so for me it's kmenu entries. I also 
have hotkeys setup to launch anything I use regularly, including my 
various pan instances, and therefore never have to actually open the 
regular kmenu unless it's for something I don't regularly enough to have 
a hotkey configured for it.  Of course, various other desktop 
environments should be similarly customizable if desired.)

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