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

[Yuya Nishihara]

On Sun, 18 Jun 2017 21:01:03 +0200, Pierre-Yves David wrote:
> 
> 
> On 06/15/2017 05:48 PM, Yuya Nishihara wrote:
> > On Thu, 15 Jun 2017 11:21:33 -0400, Augie Fackler wrote:
> >>> On Jun 15, 2017, at 11:19, 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
> >>>
> >>>> +    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.
> >>
> >> Yeah. Nobody seems motivated enough to do that work, which I totally get, so I did "done" instead of "clean". If it ever gets to be enough of a pain we can refactor, and we can maybe fix it up if we ever redo configuration to be a stack of immutable objects.
> >
> > Nobody except for Jun. I'll review this patch more carefully tomorrow and
> > probably queue it.
> 
> A registry of config option including default value would also fit that 
> need. the tweak default knob could update these default in (a copy of) 
> the config registry. That would skip the explicit update of the config 
> content (and associated concerns).

So it's a kind of config layer like defaults -> u/tcfg -> ocfg? Perhaps that
will solve the issue of inserting tweaked defaults without overriding.

> There have been talk about such registry of option for quite some time 
> (including at the 4.2 central sprint). David Demelier ping me about 
> this[1] again 10 days ago and found some time to poke at it yesterday.
> 
> It turned out I ended up with something that work, I've started 
> patchbombing it[2]. Once this is in, we can update the tweakdefault flag 
> to use this.
> 
> [1] as part of his quest for 
> https://www.mercurial-scm.org/wiki/ConfigConsolidationPlan
> [2] 
> https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-June/099866.html

These patches look a good move, though I think the config registry idea is
bloated a bit. Suppose we have tons of config items, I don't think it's good
idea to register them per item.