<<< Date Index >>>     <<< Thread Index >>>

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