yaml-language-server
yaml-language-server copied to clipboard
Support YAML completion for different hierarchy syntaxes
Is your enhancement related to a problem? Please describe.
Currently, I'm frustrated because completion does not work for these both cases:
level1:
level2:
or:
level1.level2:
In one case, I have completion, but not in second case (or the opposite, up to schema definition).
Describe the solution you would like
it would be great if completion engine can consider these two syntaxes as the same, and so, provide the same completion.
To be more concrete, it would be great that this schema definition brings completion for both syntaxes:
{
"level1": {
"type": "object",
"properties": {
"level2": {
"type": "string"
}
}
}
}
@fbaligand Your samples is not equivalent, in first sample you have mapping(object) with key level1
with nested mapping with key level2
. In second semple you have mapping with key leve1.level2
. Also .
is not part of YAML Indicator Characters so it doesn't have any specific semantics.
Your proposal is going outside of YAML specification.
Well, I did a little mistake in my second example: I mean level1.level2
.
That is equivalent up to my known.
All frameworks/tools (I know) that use YAML configuration consider and process the 2 syntaxes as the same. For instance: kubernetes, spring, all Elastic stack products (elasticsearch, logstash, kibana, beats, ...)
@fbaligand Can you point to some doc/spec where that syntaxes defined/described?
I must admit that I don't find a "clear" specification about this in YAML documentation.
There are several references to "compact in-line notation" that can be used. But no explicit example with "key1.key2"
.
Example here
That can be a problem, as YAML allows to have keys with dots, this feature can produce false validation errors and wrong codecompletion for files which uses .
in their key names.
Maybe @gorkem and @JPinkney have other opinion?
Like Yevhen said, I think this would be hard to support and would probably produce validation errors and incorrect completion because we won't know if the yaml key is in compact form or if the key just has a .
in it
Despite I understand your concern, I'm very sad to hear that. When you have a complex YAML structure with several hierarchy levels, the final user can use several ways to write the same configuration (Kubernetes is a very good example). And it is very frustrating for the user to not have completion for his YAML file, given the syntax he used. And he can think that the plugin is buggy.
Thus, based on the schema, I really think that completion can be provided for keys defined in schema. Then, if there are cases where are "free" keys with "dots", well there is just no completion for that and it is OK for validation, especially since by default, additionnalProperties=true for an "object" entry.