Force refresh by user

[lrq3000]

We already have failsafes to try to prevent tqdm from taking too much time between two updates, but they are triggered only after the first long gap, not before (else, we would need to check time() often, and this would kill the performance).

An alternative would be to allow the user to force the bar to print the current state (whether it has changed or not). I will here focus on a console environment, we can see later for other environments (IPython, GUI, etc. they should be easier).

To do that in a console, we can either activate mouse clicking, or register and catch some kind of interrupt that would be triggered by the user pressing a set of keys.

I think both are portable to any OS, so the only two criteria we should meet are: reliability (triggering the refresh should always work instantly) and no conflict (with the console's predefined shortcuts or the parent application using tqdm).

NB: And if multiple bars are displayed at the same time, we can just force them all to refresh without discrimination, that's not a problem.

[lrq3000]

After a bit of googling, it seems we are looking for a "non-blocking console input in Python". I also found a few leads:

• http://rosettacode.org/wiki/Keyboard_input/Keypress_check#Python
• http://www.darkcoding.net/software/non-blocking-console-io-is-not-possible/
• http://forums.xkcd.com/viewtopic.php?f=11&t=99890
• http://code.activestate.com/recipes/134892-getch-like-unbuffered-character-reading-from-stdin/

[o11c]

We can't rely on nonblocking input, because we're a library and we have no control over what happens between calls to tqdm.tqdm.update. And a major use case is calling into C libraries (but presumably the GIL will be released if they're well-behaved).

It's possible to get some input with signals, but I'm not sure it's a good idea.

There are 3 configurable termios keys: SIGINT (default ^C), SIGTSTP (default ^Z), SIGQUIT (default ^) - the first two are well-known so we shouldn't mess with them, and the last is an "emergency" signal designed to only be used if SIGINT isn't good enough.

Other terminal-related signals we can get from the terminal are: SIGCONT (after fg), SIGWINCH (if the terminal is resized), SIGHUP (if the terminal is destroyed), SIGTTIN (if we read when we're backgrounded), SIGTTOU (if we write while backgrounded - usually disabled).

Alternatively.

I suggest we unconditionally redraw everything on SIGCONT or SIGWINCH if output is to the current process's controlling terminal (even if other action happens).

Alternatively, we could set up one of the alarm/profile signals periodically - basically, if we did not refresh because iterations were short, but the next iteration ends up not happening soon enough, redraw from the signal (TODO - actually verify whether the Python VM can actually do this, or whether they are just queued up for the next instruction - I can do it in C++ easily with judicious use of volatile - admittedly most people probably couldn't do it safely).

If that doesn't work, we'd have to use threads.

[almson]

This is crazy. tqdm is a light utility library, it shouldn't take over signals or even output to the console without permission.

Just configure miniters/mininterval to print on every update, or suggest an improvement to how they're autotuned.

[lericson]

This is crazy. tqdm is a light utility library, it shouldn't take over signals or even output to the console without permission.

Just configure miniters/mininterval to print on every update, or suggest an improvement to how they're autotuned.

The problem is that tqdm does not update the terminal width properly on window change (ie exactly what the SIGWINCH signal is for), even between updates. See attached screenshot.