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