On 06/19/2017 03:54 PM, Yuya Nishihara wrote:
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 <y...@tcha.org> wrote:
On Wed, 14 Jun 2017 21:37:21 -0400, Augie Fackler wrote:
# HG changeset patch
# User Augie Fackler <au...@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.
Yes, still want the config layer approach to handle further overwrite
but this handles the lower, default layers that needs to be special anyway.
(adding David in CC as mentioned he needed something similar to make
progress on his ui.compat idea)
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.
I'm not sure what is your concerns here can you elaborate? We have about
200 known config option in core. That seems a manageable number of object.
As centralized config growth feature it will needs one item for each
config option anyway (alias, default, documentation, etc...).
Do you have an alternative idea in mind?
Cheers,
--
Pierre-Yves David
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
