[PATCH RFC] ui: add support for a tweakdefaults knob

[Martin von Zweigbergk]

On Thu, Jun 15, 2017 at 8:19 AM, Yuya Nishihara <yuya at tcha.org> wrote:
> On Wed, 14 Jun 2017 21:37:21 -0400, Augie Fackler wrote:
>> # HG changeset patch
>> # User Augie Fackler <augie at google.com>
>> # Date 1497488194 14400
>> #      Wed Jun 14 20:56:34 2017 -0400
>> # Node ID 0e5ea7a86a8021d02218c35b07366ac6081ab3fb
>> # Parent  3abba5bc34546951b11b1bd3f5e5c77b90d950d1
>> ui: add support for a tweakdefaults knob
>
> +1

I forgot to say, but definitely +1 from me too. Thanks!

>
>> +    def _maybetweakdefaults(self):
>> +        if not self.configbool('ui', 'tweakdefaults'):
>> +            return
>> +        if self._tweaked or self.plain('tweakdefaults'):
>> +            return
>> +
>> +        # Note: it is SUPER IMPORTANT that you set self._tweaked to
>> +        # True *before* any calls to setconfig(), otherwise you'll get
>> +        # infinite recursion between setconfig and this method.
>> +        #
>> +        # TODO: We should extract an inner method in setconfig() to
>> +        # avoid this weirdness.
>> +        self._tweaked = True
>> +        tmpcfg = config.config()
>> +        tmpcfg.parse('<tweakdefaults>', tweakrc)
>> +        for section in tmpcfg:
>> +            for name, value in tmpcfg.items(section):
>> +                if not self.hasconfig(section, name):
>> +                    self.setconfig(section, name, value, "<tweakdefaults>")
>
> Maybe we want tmpcfg -> {ucfg, tcfg} -> ocfg layers, but it wouldn't be
> doable right now since tmpcfg should be inserted *after* [uto]cfg are
> loaded.

I don't think I followed that, but another possible way it could work
is for tweakdefaults to behave as if the settings were updated inline,
so tweakdefaults=yes in system config would behave as if all the
tweaks happened in the system config, etc. Anyway, let's leave that
polish (whatever form it takes) for a later. I think we can live with
that little BC breakage (like we did with the environment variable
overrides by Jun).

> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel