Re: new things in 1.5.18
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