Closed BinderDavid closed 1 year ago
I wonder if we should just expose them all.
Another alternative would be to move the modules to Langage.LSP.Types.Internal....
and then expose them, so that we give the impression that they may not be stable (which is true).
so that we give the impression that they may not be stable (which is true). My impression was that for the modules exposed in this PR, there is the least likelihood that they would change, since they correspond very closely both to the LSP spec and only contain the definitions specific to one LSP request. (The types might evolve with the evolution of the LSP spec, of course, but is it likely that LSP requests are removed or merged?).
I think this is now obsolete, but we discussed at Zurihac and I'd be open to a new iteration of this.
The documentation of the types defined in the lsp-types library could be improved (cf. #419). As a first step, more modules should probably be exposed. As one step in this direction, this PR exposes all the modules which correspond to "Language features" on the official documentation site of the LSP protocol: https://microsoft.github.io/language-server-protocol/specification The mapping is not 1:1, since the official documentation is not super sensibly organized either, but maybe this choice of exposed modules is a sensible first step.