Jeff King <p...@peff.net> writes: > If it's smooth, the (50,1) case is slightly nicer in that it puts the > progress in front of the user more quickly. I'm not sure if that's > actually worth pushing an additional decision onto the person writing > the calling code, though (especially when we are just now puzzling out > the method for making such a decision from first principles). > > So I'd vote to drop that parameter entirely. And if 1 second seems > noticeably snappier, then we should probably just move everything to a 1 > second delay (I don't have a strong feeling either way).
Sounds like a good idea to me. I've already locally tweaked Kevin's patch to use (0,2) instead of (0,1) without introducing the simpler wrapper. It should be trivial to do a wrapper to catch and migrate all the (0,2) users to a start_delayed_progress() that takes neither percentage or time with mechanical replacement.
