-
Notifications
You must be signed in to change notification settings - Fork 21
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
Change Sequence[CompletionItemKind]
to Sequence[CompletionItemKind | int]
?
#344
Comments
This is actually a spec bug. In the model it is marked as optional but not as supporting custom values: This is This should be fixed upstream first. |
I can add a custom exception for this to be explicitly treated as supports custom values. |
Since we can work around it I don't think there's a big rush to fix this - especially since I assume any fix would go into 2024.x anyway? If it's better to fix it in the spec first then I'm happy to go with that. Is it enough to open a PR against the meta model and set |
The meta-model is built from TS object definitions. The change would have to be reflected where the TS object for CompletionItemKind is done. You might want to follow how this is done for ErrorCodes. |
We could backport the fix if it has high impact on older versions. But this seems like one of those cases that can go into 2024.x. |
In situations where an enum is "open" (such as here), would it be possible to update the generator to output the union of the enum and the value type it is based on?
I'm assuming (but have not checked! 😅) that this will prevent the converter we get from
lsprotocol
from rejecting values it does not recognise, but are permitted by the spec.Additional context: openlawlibrary/pygls#438
The text was updated successfully, but these errors were encountered: