introduce the hold_max option for less jumpy Seek-implementing ProgressBarIters

[djugei]

title basically :)

[djc]

Hey, sorry for the slow feedback here.

I'm sympathetic to the need for this, but generally would prefer to avoid user-facing options -- as much as possible, I think indicatif should do the right thing out of the box. This seems like something that could be enabled by default, are there reasons this should remain an option?

[djugei]

i had a similar thought, the other usecase is that for example a footer is read first, in that case the progress bar would be stuck at 100% throughout.
lots of formats do that, especially archive formats.
for not having any options that would need some detection and special casing, which i decided against.

maybe changing the non-jumping behaviour to be the default behaviour and documenting when it should be switched off would be an option though?

[djugei]

another idea: once the first seek happens keep a log of the last 10 accesses around and set progress to the maximum, possibly switch it off if the last 10 accesses were sequential

[djc]

another idea: once the first seek happens keep a log of the last 10 accesses around and set progress to the maximum, possibly switch it off if the last 10 accesses were sequential

I like the idea of applying some heuristics here. Want to do an implementation of that so we can review it?

[djugei]

@djc i have created an alternative implentation using a heuristic in #657

[djugei]

closing in favour of #657