Skip to content
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

Custom extensions of the Language Server Protocol #2028

Open
Schottkyc137 opened this issue Sep 24, 2024 · 2 comments
Open

Custom extensions of the Language Server Protocol #2028

Schottkyc137 opened this issue Sep 24, 2024 · 2 comments
Labels
feature-request Request for new features or functionality
Milestone

Comments

@Schottkyc137
Copy link

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
Copy link
Member

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.

@dbaeumer dbaeumer added the feature-request Request for new features or functionality label Sep 25, 2024
@dbaeumer dbaeumer added this to the Backlog milestone Sep 25, 2024
@csb6
Copy link

csb6 commented Oct 19, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature-request Request for new features or functionality
Projects
None yet
Development

No branches or pull requests

3 participants