Differentiate between Preferences.sublime-settings and *.sublime-settings
rwols opened this issue · comments
I would like to write a schema for LSP.sublime-settings.
But the match for *.sublime-settings is too broad.
Lines 34 to 37 in 6c0a003
This also matches LSP.sublime-settings, but that file has a different schema. It should match the file Preferences.sublime-settings exactly (and maybe rename the schema to preferences-sublime-settings or something).
Totally agree with this.
Can we make a conversation?
To append .schema after the file name, and before the extension.
If we have a JSON file with a name like SomeFile.json.
If we want to write a schema for that file, the file name for the schema would be SomeFile.schema.json
In practice that would allow for this.
If a plugin has a settings file LSP.sublime-settings and wants to create a schema for that file. The plug author can create a file LSP.schema.sublime-settings.
On vscode/content, when we receive a request for a file LSP.sublime-settings, we know that the schema file name should be LSP.schema.sublime-settings, so we read that file sublime.find_resource("LSP.schema.sublime-settings) and send it back to the server. That way we allow plugin authors to write schema files for their plugin settings.
It should match the file Preferences.sublime-settings exactly
There are also platform-specific preferences (Preferences (OSX).sublime-settings) that should also be covered by the same schema. But we can have multiple file matches so shouldn't be a problem.
If a plugin has a settings file LSP.sublime-settings and wants to create a schema for that file. The plug author can create a file LSP.schema.sublime-settings.
Having such extension for schema would mess with syntax/scopes and not allow LSP-json to run on it.
Why not LSP.sublime-settings.schema.json for example? Eventually just LSP.sublime-settings.schema and then one would force json syntax for files with schema extension.
Also..
On vscode/content, when we receive a request for a file LSP.sublime-settings, we know that the schema file name should be LSP.schema.sublime-settings, so we read that file
It wouldn't work that way. We only get request for schema content if we first associate that file name with a schema (either through initialize request or later through json/schemaAssociations request). It won't try to get the schema content for any arbitrary file.
So we would need to find all schema files upfront and associate them with file names.
Following a certain file pattern is probably OK but would limit us to associating schema to just one specific file name. Maybe there would be cases where it would be needed to associate one schema with multiple file patterns and then we're limited.
EDIT: And in fact, it's not uncommon for plugins to provide platform-specific configuration files. So I guess we could automatically add all those platform suffixes to given filename.
(In VSCode it's all done through package.json files so it's possible to express that well there)
And one more thing. It's still useful to have generic *.sublime-settings schema that sets allowComments and allowTrailingCommas, type: object and whatever else for all settings files.
If someone creates a more specific schema file, those will be merged anyway.
EDIT: Actually the merging might not be working as expected when schemas content has to be requested through vscode/content...
EDIT2: Actually merging works fine. Problem was with file name encoding when file had characters like space or parenthesis.