Thus spake Rocco Rutte [05/26/08 @ 14.38.05 +0200]: >> If so, I suppose the best thing is to let read_inc and write_inc be >> 1000 or even bigger, while letting time_inc be 10 seconds. > > Sorry, I still don't get what exactly you're trying to achieve. When > time_inc is 10s, it mostly doesn't matter what read_inc/write_inc are > set to as long as they're far below what mutt can read in 10s. You can > even set them to 1 and won't notice any difference except more accurate > results (the 10s delay and the progress counters).
The idea is to have as few progress updates as possible, without having zero. When it's zero and I open a huge folder, the lack of motion by mutt can fool me into thinking it's frozen. When there is some update, even if it's after 10 seconds, at least I know mutt is kicking. As I understood time_inc from the docs, if I set it to 10s, then I will get no updates in less thatn 10s, *but* it may still take longer than 10s to get an update depending on the values of read/write_inc. For instance, if I set read/write_inc to 20000, then mutt wouldn't be ready to post any new info by the 10sec mark. So the first update would occur later than 10s; maybe at 20s, maybe at 30s. Now, 20000 is pretty extreme, so I set read/write_inc to 5000. >> It's not a one-time symptom. I have 1.5.18 on one machine and 1.5.17 >> on another with no overlap. I rebuilt the caches fresh for 1.5.18. >> 1.5.18 insists on Fetching Headers when there are none to be fetched >> since they are already cached. It's true that mutt doesn't spend very >> *long* on the needless fetching, > > Maybe it doesn't fetch at all but displays the message. That could be > because of the progress initialization not printing messages lazily > enough. Please tell how long approximately the additional delay is for > 1.5.18. The delay is variable. Sometimes 1 sec, sometimes around 1/5th of a sec. I wondered myself if maybe mutt was printing the message even though it wasn't really fetching. >> Also, 1.5.18 has not solved my previously posted problem of the >> seemingly arbitrary need to completely rebuild the hcache for some of >> my mailboxes, even when they haven't been changed. Some of my boxes >> have > 15000 messages, so building the cache takes a long time. > > Does that happen without updating mutt? With what hcache backend? Yes, it happened in 1.5.17 as well. It happens with all backends that I could get to compile and work well on OSX: BerkeleyDB, qdbm. (gdbm builds for me but causes really odd drawing issues.) I had hoped that switching to qdbm would solve it, but no dice. What's weird is that most of the time mutt does not insist on a rebuild, but once out of every 8 (I'd guess) times I open a folder, mutt starts fetching from zero as if I had no cache at all. I have not messed with my cache, or changed my terminal encoding (which once upon a time did force a recaching, but there it made sense, since mutt had to rewrite the headers in utf8). I'll try the newest version of Berkeley, but I'm not hopeful. I used the newest qdbm and that got nowhere. -gmn
