microsoft / language-server-protocol

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

Should all server capabilities allow the corresponding dynamic registration options? #1908

Open michaelpj opened 3 months ago

michaelpj commented 3 months ago

Some, but not all, of the server capability fields in the initialize response allow providing the corresponding registration options. It's helpful to be able to do so, since the registration options type usually includes additional fields, such as the documentSelector.

Examples:

Is this just for backwards compatibility? Is there a way we could migrate the protocol to be more consistent here? It would make things simpler. For example, if you want to make use of the documentSelector capability, you can have many cases:

It's quite fiddly.

dbaeumer commented 3 months ago

Is this just for backwards compatibility?

Yes, it is only for backwards compatibility. There could be old clients which don't support options. I tired to be consistent for all new requests I introduce.

The only solution that came to my mind when doing this was adding a client capability to inform the server. But it felt a little bit like overhead. If someone has an idea I am happy to look into this again.

michaelpj commented 3 months ago

Yes, I agree that you would probably need a capability (dynamicRegistrationDuringInitialize?). You can't just say the client can ignore the excess fields, since the server might prefer to dynamically register in order to make the settings have effect.

I agree it's some overhead, but it might be worth it. In particular, I don't know whether you have any plan to eventually mark some capability settings as deprecated, so as to push implementors towards the "recommended" way of doing things? If there's a path towards one day making the more sensible behaviour the default then it seems worth taking a step down that path.