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

[CSV4ME2]

On Saturday 05 March 2011, Duncan wrote:
> 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.

alias pan='flock -n /<some_dir or file> /usr/local/bin/pan' 
to ensure 1 pan instance only,

see man flock for the gory details

C