Stephen Karl Larroque

Fixed the custom_symbols tag string extraction, now it's preprocessed once in `tqdm.__init__()`. The performance impact is 1 additional if statement in `format_meter()` with `bar_format=None`, and it's roughly the same as...

Moved all the code into its own module in `tqdm_custom`, so we can freely experiment and implement things like #228 without fearing that it will slow things down. If later...

Added two new features: - customization of indeterminate progress status (two ways: looping symbol or looping bar similarly to fish). - looping speed is not dependent on `n` anymore but...

Ok I'm fed up with this PR, so I'll leave it aside for now. It's already working pretty well, and it has gone further than what I intended at first....

The bar_format callback should be separated back into its own PR and merged with milestone >5.

Thanks for the PR, very interesting feature particularly when progress is slow (step > 1s), but there is a lot of additional new self variables calls, we should check if...

About async, shouldn't the effort be merged with #91 ? I feel like this PR is trying to implement many features at once, maybe break it up into separate, more...

To precise my idea: async should be a native feature of tqdm anyway, so I expect that implementing it in tqdm would make things more elegant and your life easier...

@cscanlin Thank you for coming back to this PR :) I think I better understand what your PR aims to do: a centralized manager for progress bars display running in...

In the end, I think this PR should be a very good and necessary complement to #329, if only because of `write()` that is not manageable with only a decentralized...