[PATCH 3 of 8] ui: add config knob for progressive mode

[Sean Farley]

Pierre-Yves David <pierre-yves.david at ens-lyon.org> writes:

> On 03/30/2015 07:26 AM, Augie Fackler wrote:
>> On Sat, Mar 28, 2015 at 05:51:03AM -0500, Mathias De Maré wrote:
>>> # HG changeset patch
>>> # User Mathias De Maré <mathias.demare at gmail.com>
>>> # Date 1427227793 -3600
>>> #      Tue Mar 24 21:09:53 2015 +0100
>>> # Node ID ea4595977e4e882b7a355e7e7430989cee3ea000
>>> # Parent  96a2ed2e01ef6033b74becfde0f79d5b61adbf11
>>> ui: add config knob for progressive mode
>>>
>>> This patch adds the ui.progressive config knob,
>>> to allow enabling a number of progressive settings,
>>> as proposed by Augie Fackler.
>>> Additional settings (none added yet) can be added to progressive mode
>>> by appending to _fixprogressive.
>>>
>>> diff --git a/mercurial/help/config.txt b/mercurial/help/config.txt
>>> --- a/mercurial/help/config.txt
>>> +++ b/mercurial/help/config.txt
>>> @@ -1411,6 +1411,12 @@
>>>       If set to ``abort``, the command is aborted.
>>>       On Windows, this configuration option is ignored and the command aborted.
>>>
>>> +``progressive``
>>> +    Enable user-friendly features. True or False. Default is False;
>>> +    If set to True, specific functionality that improves user experience
>>> +    will be enabled, even if there is no complete backwards compatibility.
>>> +    Scripts should use the environment variable ``HGPLAIN`` to avoid impact.
>>
>> We should probably have some comment here about how progressive-mode
>> is an explicitly moving target of our most-recommended configuration,
>> and that scripters should be sure to use the HGPLAIN variable.
>>
>> Other than that, and potential bikeshedding on the name of
>> `progressive` (I don't feel strongly either way about that), I'm +1 on
>> the series, modulo the behavioral fix on patch 1.
>
> I would probably goes for "experiemental.progressiveui" until at least 
> the sprint. This will give us a couple of week to test the thing before 
> committing to it with a public config. And I expect sprint bike 
> shredding to be much more efficient.

Just chiming in that instead of naming this variable 'friendly' or
'progressive,' why not call it what it is: 'backwards_incompatible' or
something similar?

That being said, I have no real preference one way or the either.