Ask questionsprepareRename: what is defaultBehavior, rationale

LSP 3.16 will introduce a new response to textDocument/prepareRename: defaultBehavior. However, from the spec, I am not 100% sure how to interpret such a response: "if [ ... ] is returned, the rename position is valid and the client should use its default behavior to compute the rename range".

Does this mean that servers could always return defaultBehavior when renaming is possible, or only in some yet-unspecified "obvious" cases, like the c-style identifier under the cursor? Renaming might be more complex in certain cases, e.g. for labels in C/Lua, which should include the colon in the rename range. Should a client then implement language-specific behavior to determine rename ranges?

Also, what is the purpose of this response, and what can be gained by implementing it client-side (to conserve traffic, ...)?

Related discussion:


Answer questions dbaeumer

The syntax is usually language specific. There is an item in the LSP land to make client and server 'agree' on that syntax since it is currently duplicated (on the client side and the server side).

Could defaultBehavior be returned if the placeholder and thing being renamed are different?

IMO yes, but it might depend on the client.

I agree with the specification part. But I don't want to put in VS Code behavior into the specification since it will equally force clients to implement what VS Code is doing. This is why I opt to have a client capability that describes the client behavior. @yyoncho and @nbfalcon what do you think the clients you know would / should do. Can you specify this for me?

Github User Rank List