Re: [PATCH 2/2] read-cache: fix incorrect count and progress bar stalling

Ævar Arnfjörð Bjarmason [off-list ref] writes:

How does the idea that we show "has been done" make sense when you
combine the progress.c API with the display_throughput(). I.e. output
like:
	
	+Working hard:  50% (1/2)<CR>
	+Working hard:  50% (1/2), 1.91 MiB | 195.00 KiB/s<CR>
	+Working hard:  50% (1/2), 2.86 MiB | 146.00 KiB/s<CR>
	+Working hard:  50% (1/2), 3.81 MiB | 130.00 KiB/s<CR>
	+Working hard:  50% (1/2), 3.81 MiB | 97.00 KiB/s, done.
...
That's another reason I'm maintaining that reporting progress as "is
being done" is the only sane way to look at it, because if you think it's
"has been done" you preclude the API from being used for cases where you
e.g. want to download 2 files, each file takes 1 minute, and you want to
show progress on the item itself.

Sorry, but I do not understand your argument here at all.

If you show "has been completed", when such a thing starts, I'd see
for a minute this:

 Downloading (0/2) ... X MiB | Y kiB/s

and then it will switch to

 Downloading (1/2) ... progress ...

and after staring at it for another minute, I'd see

 Downloading (2/2) ... done.

And such an output makes sense to me.  It is obvious, at least to
me, that the output during the first minute is telling me that it
hasn't finished but working hard to turn that "0" into "1" at the
pace the throughput thing is showing.