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 _______________________________________________ Pan-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/pan-users
