<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Jun 11, 2015 at 12:23 AM, Pierre-Yves David <span dir="ltr"><<a href="mailto:pierre-yves.david@ens-lyon.org" target="_blank">pierre-yves.david@ens-lyon.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
<br>
On 06/10/2015 11:01 PM, Gilles Moris wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Le 10/06/2015 21:02, Pierre-Yves David a écrit :<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
# HG changeset patch<br>
# User Pierre-Yves David <<a href="mailto:pierre-yves.david@fb.com" target="_blank">pierre-yves.david@fb.com</a>><br>
# Date 1433962615 25200<br>
# Wed Jun 10 11:56:55 2015 -0700<br>
# Node ID 00e625c98575d0e6c93b57faaf741093285fd4b5<br>
# Parent f81552058c8b90a5caca16aebe7fc2cb6de2d837<br>
progress: move config help into core config help<br>
<br>
This is core feature now.<br>
<br>
diff --git a/hgext/progress.py b/hgext/progress.py<br>
--- a/hgext/progress.py<br>
+++ b/hgext/progress.py<br>
@@ -9,32 +9,10 @@<br>
This extension uses the progress information logged by hg commands<br>
to draw progress bars that are as informative as possible. Some<br>
progress<br>
bars only offer indeterminate information, while others have a definite<br>
end point.<br>
-<br>
-The following settings are available::<br>
-<br>
- [progress]<br>
- delay = 3 # number of seconds (float) before showing the progress bar<br>
- changedelay = 1 # changedelay: minimum delay before showing a new<br>
topic.<br>
- # If set to less than 3 * refresh, that value will<br>
- # be used instead.<br>
- refresh = 0.1 # time in seconds between refreshes of the progress bar<br>
- format = topic bar number estimate # format of the progress bar<br>
- width = <none> # if set, the maximum width of the progress information<br>
- # (that is, min(width, term width) will be used)<br>
- clear-complete = True # clear the progress bar after it's done<br>
- disable = False # if true, don't show a progress bar<br>
- assume-tty = False # if true, ALWAYS show a progress bar, unless<br>
- # disable is given<br>
-<br>
-Valid entries for the format field are topic, bar, number, unit,<br>
-estimate, speed, and item. item defaults to the last 20 characters of<br>
-the item, but this can be changed by adding either ``-<num>`` which<br>
-would take the last num characters, or ``+<num>`` for the first num<br>
-characters.<br>
"""<br>
def uisetup(ui):<br>
if ui.config('progress', 'disable', None) is None:<br>
ui.setconfig('progress', 'disable', 'False', 'hgext-progress')<br>
diff --git a/mercurial/help/config.txt b/mercurial/help/config.txt<br>
--- a/mercurial/help/config.txt<br>
+++ b/mercurial/help/config.txt<br>
@@ -1212,10 +1212,48 @@ profiling is done using lsprof.<br>
Show at most this number of lines of drill-down info after each<br>
main entry.<br>
This can help explain the difference between Total and Inline.<br>
Specific to the ``ls`` instrumenting profiler.<br>
Default: 5.<br>
+``progress``<br>
+------------<br>
+<br>
+Mercurial hg commands can draw progress bars that are as informative as<br>
+possible. Some progress bars only offer indeterminate information,<br>
while others<br>
+have a definite end point.<br>
</blockquote>
<br>
We lost the default values for all those config knob.<br>
I think we should keep them.<br>
</blockquote>
<br></div></div>
Hum true.<br>
<br>
That's probably a maintenance nightmare to put them in the doc but having them displayed somewhere is important, so I guess that the doc is the best place.</blockquote><div><br></div><div>This touches on existing problems with config option documentation:<br><br></div><div>* Config options for extensions don't get documented in `hg help config` (only in the help for an extension)<br></div><div>* It is easy to add config options without documenting them<br><br></div><div>I'm generally interested in making docs/help suck less. One idea I had was to declare config options using decorators/functions. e.g.<br><br></div><div>@config('histedit', 'defaultrev')<br></div><div>def defaultrev():<br></div><div> """The default revision to use for ``hg histedit``.<br><br></div><div> ``hg histedit`` requires a revision argument. When this option is defined,<br></div><div> its value will be used when no option is provided on the command invocation.<br> """<br><br></div><div>"Strong typing" of config options could open the door to some interesting possibilities:<br></div><div><br></div><div>* Having config option functions validate seen values. If there are multiple use sites, we only have to write the validation code once instead of potentially at every use site.<br></div><div>* Error if an undocumented config option is looked up (probably from tests only - at least initially - but better than nothing)<br></div><div>* Removing typing from lookups. If config options declare their types, ui.config() can do the right thing and callers don't need to be bothered with configbool(), configint(), etc.<br><br></div><div>I concede that decorators and functions may seem a bit heavyweight for declaring options. And, loading all the Python modules just to display "hg help config" seems like a step in the wrong direction. I'm open to other ideas for solving the problems outlined above.<br></div></div></div></div>