Steven D'Aprano posted on Sun, 26 Jun 2011 14:20:39 +1000 as excerpted: >> I suppose one way around that would be a simple post-slot based ring- >> scheme. Choose some arbitrary number of auto-save messages, and when >> pan reaches that limit, it simply deletes the oldest to make room for >> the next one. If the number is say 100 messages, then message 101 will >> replace message 1. > > /me tries to stay calm. > > Please. Do. Not. Silently. Delete. My. Data. > > EVER.
That's why I suggested making the size of that ring-buffer a config option, possibly exposed only in the config file itself (not in the GUI), thus keeping the user settings simple, but exposing the option at least in the config file, for those who want to set it. Set it to something like a million (or 4.294+ billion, the 32-bit unsigned long limit), and it never deletes. Set it to 100 or so, and it automatically controls the space it requires by ring-buffering. Set it to 0 and it disables that functionality. I proposed something like 100 be the default, simply to keep pan's storage needs from ever expanding in much the same way the 10 MB cache size default does, however unreasonable I find it for my own use, but at least the value is available to tweak in the config file for those who wish to. =:^) OTOH, as a KDE user I'd be more than happy to have all those config-file- only settings exposed in the GUI, but with gnome-3 going even more config- nazi than gnome-2, and with pan being at least in name a gnome app even if it's really only gtk dependent... Anyway, I don't disagree with anything in your post. It's just that I was looking at it from the perspective of least change from current to get the named feature. Yes, having a proper sent-posts feature that didn't interfere with downloads (two separate concepts, I never did understand why Charles couldn't simply implement them that way, but then it's always easy to call the shots when you're not doing the coding) would be quite useful, even arguably a basic feature, that pan's missing now. And similarly with auto-save. But I was just thinking in terms of least change from current to get the auto-save, and how it might be implemented, with reference to the past implementation and the problems it had. -- 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 https://lists.nongnu.org/mailman/listinfo/pan-users
