[PATCH RFC] ui: introduce sysdefault section for pager and editor configuration

[Jun Wu]

Excerpts from Jun Wu's message of 2017-03-09 18:52:34 -0800:
> Excerpts from Sean Farley's message of 2017-03-09 18:49:18 -0800:
> > Kevin Bullock <kbullock+mercurial at ringworld.org> writes:
> > 
> > >> On Mar 8, 2017, at 18:06, Jun Wu <quark at fb.com> wrote:
> > >> 
> > >> A "sysdefault" section sounds a bit weird. Usually files under "/etc" are
> > >> defining "system defaults". A new section also makes it harder to see what
> > >> configs they are overriding.
> > >> 
> > >> How about appending ":sysdefault" to normal configs? The idea was also
> > >> mentioned by Yuya at [1] and we use them in "[paths]":
> > >> 
> > >>  [ui]
> > >>  pager:sysdefault = sensible-pager
> > >>  editor:sysdefault = sensible-editor
> > >> 
> > >> This makes it easier to see what configs they are overriding, and makes the
> > >> section less crowded if we want the same thing for other sections.
> > >
> > > I like that idea.
> > 
> > I guess I don't follow since I think of things in /etc as the system
> > defaults to begin with. Are we having a namespace clash with users
> > having 'foo=BAR' set so that setting 'foo' in /etc won't override that?
> 
> The point is to define configs that cannot be overrided by environment
> variables. If we check "source", and treat things in "/etc" differently, we
> may get rid of this. But that may make the config system more complicated.

I forgot to mention I have a half-complete series that changes "config" to
layered, immutable config objects that are chainned together. So we can
figure out layers of configs easily. However, that also introduces some
overhead, especially when we want to maintain correct order of config items.

If we decide to go the modern way of having layered immutable configs, at
the cost of scarifying perf or memory usage, I can polish and send that
series.