feat(lsp): add `tombi/getSchemas` command to fetch the current document schemas #1444

noirbizarre · 2026-01-14T13:16:43Z

Hi 👋🏼

Following #1423, I now have the LSP schemas listing since the release v0.7.19 (thanks for it) but I was still missing the document schemas. I tried using the hover and/or goToDefinition, but this only works on a valid statements so it's not possible to know which schemas is active on an empty document, on root whitespaces or on invalid nodes.

Given it seems not that complicated as the schemas were already retrieved at multiple place, I gave it try.

So there it is, this PR adds:

a tombi/getSchemas LSP method with its documentation, it returns the same format that tombi/listSchemas
allows optional title and description on config schemas

Schema declared using the schema directive have a special name "Document Directive Schema"

Copilot

Pull request overview

This PR adds a new LSP command tombi/getSchemas to fetch the resolved schemas for a TOML document. This complements the existing tombi/listSchemas command by returning document-specific schemas that are active for a particular file, including schemas from configuration, catalogs, and document directives.

Changes:

Added tombi/getSchemas LSP command with handler implementation
Extended schema configuration to support optional title and description fields
Added SchemaSource enum to track schema origins (Catalog, Config, Directive)

Reviewed changes

Copilot reviewed 20 out of 20 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
www.schemastore.org/tombi.json	Added `title` and `description` properties to RootSchema and SubSchema definitions
docs/src/routes/docs/language-server/command.mdx	Added documentation for the new `tombi/getSchemas` command
docs/src/routes/docs/configuration.mdx	Updated schema configuration documentation to include `title` and `description` fields
crates/tombi-schema-store/src/store.rs	Updated schema initialization to use title/description from config and set schema source
crates/tombi-schema-store/src/schema.rs	Added `SchemaSource` enum to track schema origin
crates/tombi-lsp/src/handler/get_schemas.rs	New handler implementation for `tombi/getSchemas` command
crates/tombi-lsp/src/handler/list_schemas.rs	Made `SchemaInfo` cloneable and deserializable for reuse
crates/tombi-lsp/src/backend.rs	Added `get_schemas` method to Backend
crates/tombi-lsp/src/lib.rs	Registered new custom method and exported types
crates/tombi-config/src/schema.rs	Added `title` and `description` fields to RootSchema and SubSchema, implemented Default trait
crates/tombi-lsp/tests/test_get_schemas.rs	Added test coverage for the new command
Multiple test files	Updated to use `..Default::default()` for schema construction

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

docs/src/routes/docs/language-server/command.mdx

crates/tombi-lsp/src/handler/get_schemas.rs

…nt schemas

ya7010 · 2026-01-14T13:36:41Z

crates/tombi-formatter/src/lib.rs

                            toml_version: None,
                            path,
                            include: vec!["*.toml".to_string()],
+                            ..Default::default()


It would be better to make this clear so that additions to elements can be detected at compile time.

title: None, description: None

ya7010 · 2026-01-14T13:41:31Z

crates/tombi-schema-store/src/schema.rs

+pub enum SchemaSource {
+    Catalog,
+    Config,
+    Directive,


There are at least the following three patterns:

Injection via Third Party VSCode Extension

Injection via Command

Injection via Comment Directive

Since these classifications are very difficult, it would be wise not to specify them.

ya7010 · 2026-01-14T13:46:41Z

crates/tombi-lsp/src/lib.rs

    .custom_method("tombi/getStatus", Backend::get_status)
    .custom_method("tombi/getTomlVersion", Backend::get_toml_version)
    .custom_method("tombi/listSchemas", Backend::list_schemas)
+    .custom_method("tombi/getSchemas", Backend::get_schemas)


tombi/getStatus command already exists, so it would be better to add rootSchema and subSchemas there.

interface GetStatusResponse { tomlVersion: string; source: "comment" | "schema" | "config" | "default"; configPath?: string; ignore?: "include-file-pattern-not-matched" | "exclude-file-pattern-matched"; schemaPath?: string; subSchemas?: { root: string; schemaPath: string; }[] }

ya7010 · 2026-01-14T13:58:25Z

crates/tombi-config/src/schema.rs

-#[derive(Debug, Clone, PartialEq)]
+#[derive(Debug, Default, Clone, PartialEq)]
 pub struct RootSchema {
+    /// # Title of the schema


JSON Schema may include title/description. I prefer not to set information redundantly if it's already in the schema file.

I don't think it's a good idea to add title/description to config.

ya7010 · 2026-01-17T07:03:45Z

@noirbizarre

I've created a PR to update getStatus.
#1447

Adding title/description to the schema might require significant changes to existing code.

Do you need title/description for your use case?

noirbizarre · 2026-01-18T13:01:56Z

@ya7010 Sorry, I didn't had an opportunity to get back on it before today.

I'll answer all your questions/remarks there:

Do you need title/description for your use case?

Yes, at least the title. It's for user facing display (status bar, reporting...). While I can work around for JSON Schema Store schemas by rematching with the URI, I can't for tombi internal schemas, config schemas... And it's duplicating the LSP work.

Adding title/description to the schema might require significant changes to existing code.

I haven't yet read your PR, but is it due to embedding this into getStatus ? Because it felt natural when I did this PR as those data were already in the store.

JSON Schema may include title/description. I prefer not to set information redundantly if it's already in the schema file.
I don't think it's a good idea to add title/description to config.

The way I see it, the config is just another store. JSON Schema Store catalog entries are <uri, name, description> while the schemas can also have name and descriptions too.
It's because if you don't provide it, you need to open the schema and parse it to actually have its name and description. When relying exclusively on the LSP to display data, it means that you need to do it on your own and it's not always possible (ex: in a cloud based IDE, an LSP running server-side can actually access the private company registry while the client can't access it.

Also name and description in addition to being documentational (the user using it may not be the user that created the config), it also serves in case the schema URL is broken: instead of having just a broken URL, which can be opaque, to find back the schema, you can have its name and description. For end users, it's easier to ask, "Eh, the {name} schema URL is broken, do you know what the new URL is?" than "Eh, https://some.internal.server/some/opaque/path is broken, do you know what it was?". Sure, it may find someone knowing what it was, or someone that can say what schema it is from the file itself, but it create some dependency from non-knowledgeable users on knowledgeable users.

There are at least the following three patterns:

Injection via Third Party VSCode Extension

Injection via Command

Injection via Comment Directive

Since these classifications are very difficult, it would be wise not to specify them.

I thought it was a good idea to keep the origin of a schema (at least to be able to answer "where does it come from" and "why is it active".
I had multiple possible implementations; I chose this one, but after thought, maybe another alternative was better: filling the catalogUri with:

the catalog URI if it come from a Catalog
the file URI when it's the schema directive (eg. something like file://path/to/file#:schema)
the config file URI when it comes from the config (eg. file://path/to/tombi.toml or file://path/to/pyproject.toml)
some special URI for LSP association (eg. lsp://tombi/associateSchema)
...

WDYT ?

ya7010 · 2026-01-18T17:34:28Z

The way I see it, the config is just another store.

I think a lot of this differences in opinions come down to whether we're basing it on Schema Store or JSON Schema.

Config and SchemaStore are just ways to fetch schemas. URI/Path is the simplest way to represent them.

TOML might get its own schema language down the line, and SchemaStore is a simple system without stuff like version control, so we can't really revolve everything around SchemaStore.

I haven't yet read your PR, but is it due to embedding this into getStatus ?

This is mainly due to attempting to support subschemas.

The existing mechanism does not consider title/description, requiring a major overhaul.
It's not something we can get from the SchemaStore list, either.

I thought it was a good idea to keep the origin of a schema (at least to be able to answer "where does it come from" and "why is it active".

Your idea is good. The problem is that LSP association is a method, not a origin.
There are cases where we can't figure out the origin, so it's probably smarter not to show it to avoid confusing people.

ya7010 · 2026-01-19T03:21:00Z

In the previous discussion, there was no reason to dynamically switch the configurations specified in Config, so the motivation for title/description is not strong.
Also, what about the title/description of the schema specified in the comment directive?

For now, I will limit it to obtaining only the available title/description and focus on the first release of new getStatus API.

Implementing sub-schemas has been a bit challenging, and I haven't worked on Tombi for a while, so I've forgotten the knowledge. I need some time for the new API.

noirbizarre · 2026-01-20T01:34:33Z

Don't worry, I am already thrilled you took time to answer and time to implement.
Here I am just trying to share my reasoning; it doesn't mean that everything is important right now. It's a very interesting case to me and I get learn more on both LSPs and Schemas handling.

If sub-schemas are challenging, maybe they can be left-out in the initial implementation. I think the most important is the root schema:

it's the one presented to the user (in case of a picker), and the one he might know/remember
for statusbar display, it's the most important information
partial schemas are tied to it, so have the root one already gives an hint
sub-schemas are more important on hover, go to definition and linting

ya7010 · 2026-02-08T15:15:20Z

@noirbizarre

Sorry for the delay, but I've updated getStatus to return schema info in v0.7.28. subSchemas aren't supported yet, but this should help move your work along.

noirbizarre · 2026-02-08T19:03:34Z

Oh thank you very much!! 🙏🏼
I'll try that tonight!
Don't worry, sub-schemas are less important, the main data being the main schema (users are more interested into knowing that the file matched with a project.toml schema than knowing that there is a pytest section inside of it).

noirbizarre requested a review from ya7010 as a code owner January 14, 2026 13:16

Copilot AI review requested due to automatic review settings January 14, 2026 13:16

Copilot started reviewing on behalf of noirbizarre January 14, 2026 13:17 View session

Copilot AI reviewed Jan 14, 2026

View reviewed changes

docs/src/routes/docs/language-server/command.mdx Outdated Show resolved Hide resolved

crates/tombi-lsp/src/handler/get_schemas.rs Outdated Show resolved Hide resolved

crates/tombi-lsp/src/handler/get_schemas.rs Outdated Show resolved Hide resolved

noirbizarre force-pushed the feat/get-schemas branch 4 times, most recently from 98b1c32 to 09d1550 Compare January 14, 2026 13:38

feat(lsp): add tombi/getSchemas command to fetch the current docume…

a22b2d2

…nt schemas

noirbizarre force-pushed the feat/get-schemas branch from 09d1550 to a22b2d2 Compare January 14, 2026 13:39

ya7010 reviewed Jan 14, 2026

View reviewed changes

ya7010 closed this pull request by merging all changes into tombi-toml:main in 7e802f3 Jan 17, 2026

BrewTestBot mentioned this pull request Jan 20, 2026

tombi 0.7.20 Homebrew/homebrew-core#263610

Merged

Uh oh!

feat(lsp): add tombi/getSchemas command to fetch the current document schemas #1444

feat(lsp): add tombi/getSchemas command to fetch the current document schemas #1444

Uh oh!

Conversation

noirbizarre commented Jan 14, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Uh oh!

Uh oh!

ya7010 Jan 14, 2026

Choose a reason for hiding this comment

Uh oh!

ya7010 Jan 14, 2026

Choose a reason for hiding this comment

Uh oh!

ya7010 Jan 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ya7010 Jan 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ya7010 Jan 14, 2026

Choose a reason for hiding this comment

Uh oh!

ya7010 commented Jan 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

noirbizarre commented Jan 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ya7010 commented Jan 18, 2026

Uh oh!

ya7010 commented Jan 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

noirbizarre commented Jan 20, 2026

Uh oh!

ya7010 commented Feb 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

noirbizarre commented Feb 8, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

feat(lsp): add `tombi/getSchemas` command to fetch the current document schemas #1444

feat(lsp): add `tombi/getSchemas` command to fetch the current document schemas #1444

ya7010 Jan 14, 2026 •

edited

Loading

ya7010 Jan 14, 2026 •

edited

Loading

ya7010 commented Jan 17, 2026 •

edited

Loading

noirbizarre commented Jan 18, 2026 •

edited

Loading

ya7010 commented Jan 19, 2026 •

edited

Loading

ya7010 commented Feb 8, 2026 •

edited

Loading