Re: new things in 1.5.18
Hi,
* dv1445@xxxxxxxxx wrote:
OK, so am I right that the following are my options? On the one hand,
I could set read_inc and write_inc to zero, which means there will be
no fractions or percentages; however this would make it pointless to
set time_inc to a large value, since I would get no updates anyway.
Well, not pointless, because there's net_inc too, and maybe I want to
see progress updates on the uploading and downloading of files, but
only for big files that take a long time.
On the other hand, I could leave read_inc and write_inc at 1000, and
set time_inc to something large (now it's 10000); this way, I'd see
fractions and percentages, but: (1) they won't be updated unless the
process takes more than 10 seconds, and (2) if it takes more than ten
seconds the only updates I see will be things like (12000/15545) "on
the thousands" rather than (12878/15545).
Is that right?
Yes.
Though I still think you slightly misinterpret the meaning of $time_inc.
It isn't supposed to set the limit for when to display progress (that's
what $read_inc/$write_inc/$net_inc are for), but it's supposed to
prevent too frequent updates as that may a) limit the operation speed
(for remote sessions over slow links) and b) may be annoying due too
much activity.
For example, one may have a local and a remote IMAP server. $read_inc
could be 10. The problem is that this value may be too high for the
remove server on slow links but far too low for local servers as the
link is way faster. That's where $time_inc comes into play. You can tell
mutt to update the progress every 10 messages but not more than twice a
second with $time_inc = 500.
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).
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.
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?
Rocco