pan-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Pan-users] Re: Can I tell Pan, with one command, to watch many threads?


From: Duncan
Subject: [Pan-users] Re: Can I tell Pan, with one command, to watch many threads?
Date: Wed, 22 Dec 2010 06:14:12 +0000 (UTC)
User-agent: Pan/0.133 (House of Butterflies; GIT 25ed40d branch-testing)

Beartooth posted on Tue, 21 Dec 2010 19:38:32 +0000 as excerpted:

> When I come to a group I haven't gotten to for a while, or use a
> backup machine, I often want to tell Pan to watch several threads at
> once -- especially ones I started, which have gotten new answers, or
> answers not marked read on the current computer.
> 
>       I can get them into batches easily enough, sorting by author; I
> can highlight one, scroll down, hold Shift, and highlight another, thus
> highlighting a whole batch. But if I then right-click and choose "Watch
> thread," it doesn't.
> 
>       Is there a way? Or hope for one?
> 
>       Might I even be able to tell a given group's preferences to watch
> all of the treads I start, or all I participate in??

What pan does with watch-subthread is look at the message-id of the 
current message and create s "watch" (=9999) score entry for that
message-id, when it appears in the references header.  

A reply message, BTW, is supposed to take the existing references header 
and add the message-id of the messsage being replied to, to it, the result 
being that the references header contains a list of parents reaching back 
to the original post.  (When the nesting gets very deep, there's a 
mechanism that allows deleting some messages from the references header 
list, so the references header doesn't get /too/ long, but that's an 
exception.)

The result of the score pan applies in paragraph 1 is that any children 
(and their children and...) of said message get scored as "watched", that 
is, =9999.

Pan applies a similar mechanism with watch-thread, except that it finds 
the top parent (the original thread-starting post), and applies the score 
to its message-id in the references header.  Since it's applying the score 
to the message-id of the original post, the "sub-thread" is the entire 
thread, so this is actually just a special case of "watch-subthread".

As a result of this, for pan to watch all selected threads (or subthreads), 
it'd have to find the message-id for each one and apply the score to all 
of them.  To my knowledge, pan's not that sophisticated, unfortunately, 
and can only handle that task one at a time.

Similarly, it's no big deal to tell pan to watch your own posts, or those 
of any other author, since that's a single entry in the score file.  But 
it can't be set to watch the entire threads (or subthreads) for such 
posts, because it doesn't know the message-ids to add to the scores it 
creates until it actually sees the messages, and pan is too simple to work 
ahead, like that.

Now if we had rules, like old-pan (0.14.x, before the C rewrite) did, 
conceivably it would be possible to create a rule using a particular score 
entry (in this case the entry that says watch all posts by author, you), 
with watch-subthreads as the action.  Unfortunately, Charles was reluctant 
to add those to the C++ rewrite because he thought rules were too complex 
for a lot of people to be able to work with.  He was right, they were 
rather complex, and there was talk of simpler replacements, but 
unfortunately, they never got implemented either.  Rules or rules-
replacements was one of the few features of old-pan, certainly the 
biggest, that never got implemented in new-pan.  (There were a handful of 
others that weren't, simply because they didn't make sense with the way 
new-pan worked, regarding multiple-server handling, for instance, but 
rules was the biggest major feature that simply wasn't implemented in new-
pan, nor was a replacement.)

Unfortunately, while pan's a gtk app, not specifically gnome, it is within 
the gnome family, and IMO this might be yet another victim of gnome's keep 
it simple at the expense of useful functionality approach to things.  
Rules were seen as "too hard", and so pan users must now do certain 
repeated tasks manually, one at a time, that with old pan it was possible 
to automate.

Meanwhile, Charles has indicated that he's no longer particularly 
interested in maintaining pan longer term, as he no longer uses newsgroups 
much if at all.  He has practically begged for someone with the 
appropriate skills and love for pan to step forward and take over, but 
unfortunately, no one has stepped up.  (KHaley's the closest we've gotten 
and he has specifically stated he's not interested in being official pan 
head developer.)  As a result, at present, pan's mostly being merely 
maintained as is, kept building against newer libraries with a newer 
toolchain, plus a few small features, and that's it.  Thus, at this point 
it's rather unlikely that pan will ever see this functionality again. =:^(

If, and at this point it's a bit IF, someone eventually does step up and 
take a true interest not only in continuing to keep pan working, but in 
new development, it's quite possible that either rules, or the simpler 
alternatives previously discussed, would be near the top of the new-
feature list, particularly since pan did once have that functionality 
(altho at this point it'd almost be brand-new functionality, since it'd be 
the first time implemented in C++ pan and the C version with that 
functionality was very likely before many current user's interest in pan).

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]