gittup
progress bars less than optimal
in a situation like this, the progress bars didn't quite make sense to me:
[ tup ] [0.000s] Scanning filesystem...
[ tup ] [0.188s] Reading in new environment variables...
[ tup ] [0.188s] Parsing Tupfiles...
1) [0.004s] .
[ ] 100%
[ tup ] [0.195s] No files to delete.
[ tup ] [0.195s] Generating .gitignore files...
[ tup ] [0.337s] Executing Commands...
1) [0.024s] AR libtup.a
2) [0.119s] LINK tup
[ ] 100%
[ tup ] [0.627s] Updated.
it took me a while to figure out that the little brackets with one or two spaces of color inside were actually small progress bars. similar to #187, it looked kinda like color spam.
when the progress bars are at full length, they look better. however, it might make sense in both cases to delete the progress bar after it has completed. otherwise while commands below, my eyes keep are very much drawn to this giant blue bar, making further work more difficult.
like i said in #187, i'm a big fan of terminal text in general, but i think tup could use a couple tweaks in that department. :-)
You could always do TERM=dumb tup. That will get rid of the progress bars altogether ;)
In reality, ANSI escapes aren't flexible enough to just 'erase' the progress bars. That would require a lot of assuming about the terminal in question - and make for a really, really unreliable solution.
One solution is to just write the progress textually, much like ninja does: 16 / 155.
See also the display.progress option, which can be set to false to just display a percent complete & job number on each line rather than an ASCII progress bar. There are a few other display options to configure it as well.
