search

microsoft / language-server-protocol

Defines a common protocol for language servers.
https://microsoft.github.io/language-server-protocol/
Creative Commons Attribution 4.0 International
11.22k stars 797 forks source link

Custom extensions of the Language Server Protocol #2028

Open Schottkyc137 opened 4 weeks ago

Schottkyc137 commented 4 weeks ago

For some languages (concretely thinking about hardware description languages such as VHDL or Verilog, but this probably applies to more), there are certain desirable features that are not covered by the language server protocol, but that are small enough so these features would likely not be implemented into the mainline protocol. As one concrete example: These language description languages usually have a notion of instantiated units that form a hierarchy of sorts. This hierarchy is similar to the notion of a CallHierarchy or TypeHierarchy yet cannot be expressed satisfactorily or semantically correct with either capability. At the same time, it is also not practical to implement support for such InstantiationHierarchy (or similar) capabilities into the mainline protocol because most languages will never use this capability it and therefore most editors won't enable support for the capability. In my opinion, these kinds of features would best be implemented as part of a custom extension of the Language Server Protocol. Plugins in editors (thinking especially about VSCode, but this is widely applicable) could tune into these extensions and provide the client side implementation of the protocol. The Base LSP is still applicable, but the method names, appropriate parameters and responses would be custom. My question therefore is: Is there a 'standard' way of extending the Language Server Protocol to implement these niche features? I.e., is there a certain namespace or schema for method names that can or should be used to implement custom capabilities and does LSP even allow or encourage extensions? And if it doesn't so far, would this make sense?

dbaeumer commented 3 weeks ago

I am in support of those extensions and the npm modules for VS Code support to plugin features into the existing client and server.

We could manage the names of these requests still in the LSP protocol but leave the spec and implementation to someone outside of the protocol. This ensures that no name is taken twice.

csb6 commented 4 days ago

This paper by Rask et al. (I am unaffiliated) describes an LSP extension intended for languages that support specification or proof-related tasks, such as Dafny, Lean, Alloy, Isabelle, the Vienna Development Method (VDM), etc.

There is already an implementation of the extension (called SLSP for Specification LSP) in the VDM VSCode extension here, which might be a useful reference.