Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Complete reference docs for config options #879

Open
dbarnett opened this issue Dec 10, 2022 · 12 comments
Open

Complete reference docs for config options #879

dbarnett opened this issue Dec 10, 2022 · 12 comments

Comments

@dbarnett
Copy link
Contributor

There's a doc on configs with some info/examples, but it doesn't seem to list every supported config option. For example, I couldn't find the [alias] section mentioned anywhere in there. Could there be a complete reference doc somewhere?

And/or the schema were explicitly captured somewhere (in something like schemastore.org but for TOML, that could be hooked up to editor integrations).

@dbarnett
Copy link
Contributor Author

Related: Even from reading the code it's hard to get a complete notion of the supported schema. You can find a few details in https://github.com/martinvonz/jj/blob/main/src/config.rs but I found info about how alias and revset-aliases worked sprinkled around in cli_util.rs. Any interest in refactoring so the expected config structure is more self-contained and discoverable in the code?

@ilyagr
Copy link
Contributor

ilyagr commented Dec 11, 2022

If you'd like, you could document what you have figured out. Your example from #878 (comment) might work well in the docs.

@ilyagr
Copy link
Contributor

ilyagr commented Dec 11, 2022

I had no idea we had aliases already before I read that :)

@ilyagr
Copy link
Contributor

ilyagr commented Dec 11, 2022

Also, revset-aliases are documented here. I think there should be a mention of them in config.md as well, though. Just a link might be enough.

@martinvonz
Copy link
Member

Any interest in refactoring so the expected config structure is more self-contained and discoverable in the code?

Yes! I'd just like to make sure that we don't put UI-specific knowledge in the library crate as a result, and that we make it possible for custom jj builds (such as the one at Google) to add their own configs.

@dbarnett
Copy link
Contributor Author

Well, I put together a sketch of a JSON schema spec for jj config, but I'm not sure if I should send a PR directly to https://github.com/SchemaStore/schemastore/pulls or maybe stage a copy of it somewhere in the jj repo first. WDYT?

With that installed, taplo LSP (in vim, VS Code, etc) give nice hints about what section names and properties are supported, so there's not such an urgent need for thorough reference docs on the config format.

@martinvonz
Copy link
Member

I had never heard of SchemaStore before. I don't mind if you send them a PR, but I don't know what their policy is for accepting PRs. Would we send them a PR to update the schema roughly once per minor release (i.e. jj 0.7.0 next time) or what do you think?

@dbarnett
Copy link
Contributor Author

They seem to accept pretty much whatever. Lots of JSON validators and LSPs are hooked up to use schemas from there (and apparently also TOML ones like taplo).

update the schema roughly once per minor release

Right, I don't think there'd be much difficulty updating it in SchemaStore as often as needed, but did wonder if somehow keeping it in the same repo would be more convenient. The only thing is it seems more awkward hooking up to user tools if it lives elsewhere (maybe impossible for some tools?).

@martinvonz
Copy link
Member

Would it help if we had a command to print that JSON format? Maybe that could be jj config available or jj debug available-config. Then it would never be out of sync with the binary. I don't know how taplo would hook into it, though (I still barely know anything about taplo).

@dbarnett
Copy link
Contributor Author

I think it wouldn't because the schema needs to be tied to a public ID (a URL basically), and hooking up to any copy that's only stored locally involves extra steps. It might be worth just storing a copy in this repo (so we're more likely to remember to update it when adding new supported config options) but copy it over to SchemaStore via PRs there as well. Maybe that could even be automated.

Not sure the best model for if there are additional config options available internally at Google. It's not the end of the world if those have to be looked up manually and aren't as nicely integrated into auto-suggest, but hopefully in that special case there'd be a way to overlay a forked internal schema for googlers without too much manual setup for each user.

@dbarnett
Copy link
Contributor Author

So I think it's best to start with checking it into this repo and then figure out where it should be hosted longer term. If you can suggest a file path and a URL we could reserve for it, I can send a PR and we can follow up on the other stuff later.

Another advantage of having it available to the jj code is it could be used for introspection, user-friendly validation messages, and maybe some kind of generated reference docs.

@martinvonz
Copy link
Member

So I think it's best to start with checking it into this repo and then figure out where it should be hosted longer term. If you can suggest a file path and a URL we could reserve for it, I can send a PR and we can follow up on the other stuff later.

Thanks. I agree. For the file, I'd go with src/schemas/json/jj.json. For the pattern to match, \.jjconfig.toml|/jj/config\.toml is probably good.

Another advantage of having it available to the jj code is it could be used for introspection, user-friendly validation messages, and maybe some kind of generated reference docs.

Yes! Mercurial has a central config registration for the same reasons. We could also use it for shell completion some day, but I generally consider that blocked by clap-rs/clap#1232.

dbarnett added a commit that referenced this issue Jan 2, 2023
Can be used with tools like taplo-lsp to show hints & validation in
editors/IDEs. Won't apply automatically to config files until it's
submitted to schemastore.org, but in the meantime it can be used via a
schema directive
(https://taplo.tamasfe.dev/configuration/directives.html#the-schema-directive)
or other manual config mechanism.

Context in #879.
dbarnett added a commit that referenced this issue Jan 2, 2023
Can be used with tools like taplo-lsp to show hints & validation in
editors/IDEs. Won't apply automatically to config files until it's
submitted to schemastore.org, but in the meantime it can be used via a
schema directive
(https://taplo.tamasfe.dev/configuration/directives.html#the-schema-directive)
or other manual config mechanism.

Context in #879.
dbarnett added a commit that referenced this issue Jan 2, 2023
Can be used with tools like taplo-lsp to show hints & validation in
editors/IDEs. Won't apply automatically to config files until it's
submitted to schemastore.org, but in the meantime it can be used via a
schema directive
(https://taplo.tamasfe.dev/configuration/directives.html#the-schema-directive)
or other manual config mechanism.

Context in #879.
dbarnett added a commit that referenced this issue Jan 2, 2023
Can be used with tools like taplo-lsp to show hints & validation in
editors/IDEs. Won't apply automatically to config files until it's
submitted to schemastore.org, but in the meantime it can be used via a
schema directive
(https://taplo.tamasfe.dev/configuration/directives.html#the-schema-directive)
or other manual config mechanism.

Context in #879.
dbarnett added a commit that referenced this issue Jan 3, 2023
Can be used with tools like taplo-lsp to show hints & validation in
editors/IDEs. Won't apply automatically to config files until it's
submitted to schemastore.org, but in the meantime it can be used via a
schema directive
(https://taplo.tamasfe.dev/configuration/directives.html#the-schema-directive)
or other manual config mechanism.

Context in #879.
dbarnett added a commit that referenced this issue Jan 3, 2023
Extends TOML/JSON schema changes from #966 to allow jj to output the
schema directly. Context in #879.
dbarnett added a commit that referenced this issue Jan 3, 2023
Extends TOML/JSON schema changes from #966 to allow jj to output the
schema directly. Context in #879.
dbarnett added a commit that referenced this issue Jan 3, 2023
Extends TOML/JSON schema changes from #966 to allow jj to output the
schema directly. Context in #879.
dbarnett added a commit that referenced this issue Jan 3, 2023
Extends TOML/JSON schema changes from #966 to allow jj to output the
schema directly. Context in #879.
dbarnett added a commit that referenced this issue Jan 4, 2023
Extends TOML/JSON schema changes from #966 to allow jj to output the
schema directly. Context in #879.
dbarnett added a commit that referenced this issue Jan 4, 2023
Extends TOML/JSON schema changes from #966 to allow jj to output the
schema directly. Context in #879.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants