Provide FileOperationRegistrationOptions class
angelozerr opened this issue · 4 comments
The LSP specification defines the FileOperationRegistrationOptions which is helpful to support dynamic registration for file operations.
It would be nice if LSP4J could provide it.
Thanks!
Looks like LSP4J already provides it:
lsp4j/org.eclipse.lsp4j/src/main/java/org/eclipse/lsp4j/Protocol.xtend
Lines 8107 to 8126 in cc20058
Thanks @pisv!
I wonder why FileOperationOptions
name is used instead of FileOperationRegistrationOptions
which respects the spec?
I wonder why FileOperationOptions name is used instead of FileOperationRegistrationOptions which respects the spec?
Good question :-)
The following is my educated guess...
There are some inconsistencies regarding registration options in the spec. But usually there is a basic *Options
interface, and there is a corresponding *RegistrationOptions
interface the extends the basic *Options
interface and also extends StaticRegistrationOptions
and/or TextDocumentRegistrationOptions
.
For example, there is SemanticTokensOptions
, and there is SemanticTokensRegistrationOptions
, which extends SemanticTokensOptions
, TextDocumentRegistrationOptions
, StaticRegistrationOptions
.
The corresponding server capability semanticTokensProvider
is typed as SemanticTokensOptions | SemanticTokensRegistrationOptions
to allow for static registration of SemanticTokensRegistrationOptions
in response to the initialize
request.
SemanticTokensRegistrationOptions
can also be used for dynamic registration of the textDocument/semanticTokens
feature via the client/registerCapability
request.
Clearly, FileOperationRegistrationOptions
does not match this pattern. According to the spec, there are no dynamic registration options supported for WillCreateFiles
and similar requests/notifications. There is no FileOperationOptions
that FileOperationRegistrationOptions
would extend, and FileOperationRegistrationOptions
also does not extend StaticRegistrationOptions
.
So, despite its name, FileOperationRegistrationOptions
has nothing to do with static or dynamic registration options, as it now stands.
Also, while type names don't mean much in TypeScript with its structural typing, changing a type name in Java would be a breaking change.
Therefore, I guess it was decided to reserve the name FileOperationRegistrationOptions
in LSP4J to be able to differentiate between FileOperationOptions
and FileOperationRegistrationOptions
according to the usual pattern for registration options, when/if such a need arises.
Thank you @pisv for providing such a detailed analysis. I don't think there is anything left to do here so I am closing this issue. Please comment/reopen if I have missed something.