pan-users
[Top][All Lists]
Advanced

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

[Pan-users] Re: Watched Articles filter is 'stuck'


From: Duncan
Subject: [Pan-users] Re: Watched Articles filter is 'stuck'
Date: Sun, 3 Sep 2006 20:56:45 +0000 (UTC)
User-agent: pan 0.110 (Beable Beable)

"Nat Gross" <address@hidden> posted
address@hidden, excerpted
below, on  Sun, 03 Sep 2006 14:50:53 -0400:

> On 9/3/06, Charles Kerr
> <address@hidden> wrote:
>> Nat Gross wrote:
>> > Hi;
>> > (Have been using pan for a while and am pleased with it. Anyhow..) My
>> > 'watched articles' filter refuses to UNfilter, regardless of the
>> > position of the button.
>> > I have tried flipping the 'unread' filter back and forth, although
>> > that works, but only for watched threads. In other words, the watched
>> > filter is always on.
>>
>> What version of Pan are you using, Nat?
> 0.14.2.91 on Fedora 5 32 bit latest kernel. Gnome. I forgot to mention
> that this behaviour is only for 1 group (my most often used group).
> Other groups, the filter works normally.

As you may have read by now, 0.14.x is unmaintained now and is unlikely to
have further updates.  However, this doesn't seem to be a problem with
pan, but something in the info pan has stored for the group.  It should be
possible to delete the info for the group and have pan recreate it, thus
fixing the problem.

Just how much work you go to to figure out where the problem is and just
delete that problem, leaving everything else untouched, is up to you, and
will probably depend on how much info you are comfortable losing and
recreating.  I'd start by making a backup of the .pan/data dir (minus the
cache if you keep a big one, since this shouldn't affect that).  Then with
pan closed while making changes and using a bit of common sense on what to
try first, delete a few files at a time, restart pan, and see if the
problem still exists.  Then quit pan and restore the files if it didn't
help, and go on to the next set of files.  When you find the problem set,
working with that set, narrow it down to a specific file.  If you are
comfortable losing the info in that file, fine.  Otherwise, open the file
in a text editor and if you can make sense of it, again find the problem
section and then line by trial and error, restoring the backup copy to try
again as needed.  If you are careful and patient enough to take it that
far, you can probably reduce the lost info to a single line or at least a
single section.

I routinely use this method when I get a piece of a config that quits
working, and have been using it for a decade now, since I was running MS
Windows 95 if not earlier. As I customize rather heavily, I don't like to
blow away an entire config, and usually pinpoint the problem pretty
closely before I'm satisfied.  The method works amazingly well, and I've
learned quite a bit about where various pieces of my config are stored,
that way, thus making future fixes that much easier.

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