[Top][All Lists]
[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