[Pan-users] Re: The old, annoying and essential problem with old headers

[Duncan]

Heiko Schroeder posted on Sat, 05 Mar 2011 11:48:52 +0100 as excerpted:

> In the bugfix list, it seems as if the old and very annoying bug to
> loose old headers after entering a group twice in pan0.133 is not fixed
> in version 0.134.

Loosed from their bonds in the pit of hell? =:^)

Chances are you mean "Lose".  (It's an all too common mistake, even for 
native English speakers, which going on the name, you may not be.)

http://www.google.com/search?q=lose+loose

(I see one of the hits has a nice way to remember... "loose" with two "o"s 
has too much room in it, it's "not tight."  FWIW that one hasn't been a 
problem for me but I had the infamous too/to problem here, until someone 
pointed it out to me so I could get it right in future usage.)

> This problem is IMHO one of the most critical and essential, and I ever
> saw it on any newsreader before.  Even if you kill all crosses in the
> preferences, the behaviour is still the same.
> 
> Regards Heiko

If you use only one pan instance (I have several separate instances, each 
pointed at its own config using the $PAN_HOME environmental variable, so 
this wouldn't work well for me), consider setting up a stub-script that 
does a psgrep pan, and if it finds an existing one, it activates it, 
instead of starting a new one.  Then, however you normally start pan, 
point that launcher at the script instead of directly at the pan binary.

If you don't know how to write shell scripts or can't figure it out, I can 
write a sample for you.  However, you'd probably need to alter paths, 
possibly install a dependency (I'd probably activate the window using 
winctrl, which you'd need installed), and would probably need to be able 
to edit your chosen pan launcher to point at the script instead.  If you 
can do that and want me to, I can writeup the sample script.

Meanwhile, it's possible to extricate yourself from the double-pan-session 
thing, without loss of anything (or at least, much), if you keep your wits 
about yourself.  The key thing to realize is that pan keeps the settings 
of the /last/ one that closes, and that it saves individual group settings 
when you switch groups.  So once you realize you've started two instances, 
assess the situation before closing anything.

If you catch it soon enough, you will have just started the second session 
and won't have done anything in it yet.  Close it, then immediately close 
the old session, so it overwrites the invalid state with the state that is 
actually tracking what you've read, etc.  (Note that this still might not 
work if you have the option set that marks groups read when you leave 
them.  I don't, for a number of reasons, so it's not a problem here.  
Similarly tho less so with the automatically fetch new headers at pan 
start and when entering a group options.  That should be less of an issue 
tho, because all it should do is download a few more headers, not mark 
anything read.)

If you've actually worked in both, you'll lose a bit of state tracking in 
the first one you close, as the second one will overwrite it.  So figure 
out which one has the most unsaved state (noting that switching groups 
saves state, so you only have to worry about the group you were in when 
you started the second session, and any others that both sessions had 
visited), close the OTHER one first, then the one with the most unsaved 
state, so it overwrites the first one.

At least here, I tend to realize the mistake when I make it, right away, 
before I have any unsaved state in the second session.  So as long as I am 
sure to close the new one first, then the old one, everything works fine.

Hope that helps.

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