Convert, for example, has loops like this:
for revision in source_repo:
progress(revisions)
for file in revision:
progresss(file)
Prior to this change, we would start showing the file-level progress
when we encountered a big revision, and then we'd get stuck in showing
file-progress instead of revision progress, often producing many many
instantly-completing progress bars rather than the actually-helpful
top-level revisions bar.
ui.quiet and ui.debugflag are not initialized during uisetup and
reposetup. progressui is always initialized, therefore we have to check
during write() if ui.quiet is set or not.
When combined with the earlier change to make the progress object
truly a singleton, this prevents the progress bar swapping on 'hg
clone --pull' on a local filesystem.
Thanks to timeless for lots of debugging help at the Copenhagen sprint
to isolate the root cause of this and a first draft an idea that would
fix it.
This is not enabled by default, but the user can add it by setting
progress.format.
We might want to let the estimate format output a speed instead of an
ETA if there is not total. Currently estimate just returns the empty
string in that case.
using hg clone svn://anonsvn.kde.org/home/kde/trunk kde ... with progress
yields 3008/1210830 1314h56m, which is unusable.
Add code to switch to days at 30 hours, to weeks at 15 days, and to years
at 55 weeks. A day has 24 hours, a week has 7 days, and a year has 52 weeks.
Months are intentionally omitted because they do not have a fixed length. The
Use of 52 weeks is a known and understandable estimate for a year.
It might make sense to spell our year to alert people when progress is
impractical, but...
Previously, we'd reset the entire progress bar state when a topic was
completed, even if it wasn't the outermost progress topic. Now we
print the state of the next progress topic on the stack if one is left
rather than reset the progress bar.
This resolves the issue of hg cmd --mq not being colorized. This was due
to color wrapping only the instance of ui passed to dispatch._runcommand(),
which isn't the same ui object that mq.mqcommand() receives. After dispatch
calls extensions.loadall(), it makes sure any changes to ui.__class__ in
uisetup are propagated.
progress is updated to wrap ui in the same manner because wrapfunction
doesn't play well when ui.__class__ has been replaced by another extension
(orig will point to the old class method instead of color's).
This adds output labeling support with the following methods:
- ui.write(..., label='topic.name topic2.name2 ...')
- ui.write_err(.., label=...)
- ui.popbuffer(labeled=False)
- ui.label(msg, label)
By adding an API to label output directly, the color extension can forgo
parsing command output and instead override the above methods to insert
ANSI color codes. GUI tools can also override the above methods and use
the labels to do GUI-specific styling.
popbuffer gains a labeled argument that, when set to True, returns its
buffered output with labels handled. In the case of the color extension,
this would return output with color codes embedded. For existing users
that use this method to capture and parse output, labels are discarded
and output returned as normal when labeled is False (the default).
Existing wrappers of ui.write() and ui.write_err() should make sure to
accept its new **opts argument.
This has no effect in real world where progress.refresh in unlikely to be set
to zero, but is very useful in tests where all progress output is to be traced.
It failed on platforms with coarse time.time() granularity, like Windows+py25.
foo [ ] 0/58
foo [> ] 1/58
foo [=> ] 2/58
...
foo [=======================================================> ] 56/58
foo [========================================================> ] 57/58
foo [=========================================================>] 58/58
The bar now has a '>' character at the end. This indicates the direction,
is consistent with the indeterminate '<=>' bar, and looks much nicer.
