cli: ability to disable default configs

[dpc]

My motivation is mostly to address #5098 , but in a lot of software there's a flag to disable sourcing default configs, which is useful in a lot contexts.

A more granular (or just atlernative/better) approaches would require more design and debate, while this seems simple and immediately useful (at least to some).

Checklist

If applicable:

• I have updated CHANGELOG.md
• I have updated the documentation (README.md, docs/, demos/)
• I have updated the config schema (cli/src/config-schema.json)
• I have added tests to cover my changes

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[martinvonz]

Thanks, but JJ_CONFIG= jj should already have this effect

[dpc]

@martinvonz The JJ_CONFIG controls the user's config, no? While I'm trying to disable the default configs shipped with jj.

[martinvonz]

Oh, I'm sorry. Interesting. We have a lot of code that depends on the default configs existing, so I think it's going to be more complicated to support than this PR's current state.

[dpc]

@martinvonz I just noticed. Oops.

As a first user who'd want this, I don't mind just adding all the required keys to my config, and thus being sure I am in full control.

Also (or/and), I could add unwrap_or_default() on most obvious ones.

Also (or/and) I could add JJ_CONFIG_NO_DEFAULT_COLORS.

And (or/and), some config toml could be considered "essential", and loaded even with JJ_NO_DEFAULT_CONFIG.

[dpc]

This seems to have no issues.

[ilyagr]

For the colors issue, I wonder if it'd be better to introduce a notion of themes. So, the colors we have now would become the default theme, and you could reset them all by using another theme.

Settings like templates.log_node could also be set by a theme, though I don't think there's any reasonable "undefined" value that can have by default¹.

Recently, scoped config was introduced. I'm not 100% sure about that direction, but perhaps it's sufficient to create a "default theme" scope that contains all the color config and is activated by default. (This would hopefully be relatively easy, but it's not trivial, it still needs some design work on how these theme scopes work)

In principle, we could do this to things other than the color config, any kind of thing that people would want to "turn off" en masse, and for which leaving it "undefined" makes sense.

Footnotes

1. There are many other such settings; in my mind, any jj command is allowed to crash if the default config is not loaded. The first example that comes to mind is not merged yet, but https://github.com/jj-vcs/jj/pull/5415 would crash if you deleted the default config and tried using :builtin pager. ↩

[jakobhellermann]

Recently, scoped config was introduced. I'm not 100% sure about that direction, but perhaps it's sufficient to create a "default theme" scope that contains all the color config and is activated by default. (This would hopefully be relatively easy, but it's not trivial, it still needs some design work on how these theme scopes work)

Instead of having a "theme scope", we could introduce a generic "config scope", that is enabled when a config variable is set to a certain value:

[[--scope]]
--when.config = ["ui.enable-colors"] # equivalent to ["ui.enable-colors", "true"]
[--scope.colors]
"error" = { fg = "default", bold = true }
"error_source" = { fg = "default" }
...

or

[[--scope]]
--when.config = ["ui.theme", ":builtin"]
[--scope.colors]
"error" = { fg = "default", bold = true }
"error_source" = { fg = "default" }
...

[yuja]

I wouldn't add any "conditional" thingy that also depends on config values (and/or any other dynamic variables.) That would make resolution complicated.

For color overrides, it's probably better to add some indirection dedicated for [colors] table. #3594

FWIW, the default colors table can be reset by abusing invalid value, but please don't expect this will work forever.

[[--scope]]
colors = 0  # reset colors table by assigning non-table value
[[--scope]]
colors.commit_id = "red"