You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Client waits for a window/showMessageRequest, if it has not provided a configuration setting for [javascript/typescript].updateImportsOnFileMove.enabled. The request will look something like this:
Client sends a response to window/showMessageRequest - in this example, let's assume they respond with
{ "title": "Always", "tsId": 3 }
Internally, vtsls updates its "shim configuration service" to mock a "client configuration update", then sends workspace/applyEdit request
In subsequent notifications to workspace/didRenameFiles, vscode reads the configuration setting from vtsls's shim service and (potentially - in the case of 'always' or 'never' being previously selected) does not send window/showMessageRequest - in this example, it would automatically go ahead and send workspace/applyEdit request to apply the updates to imports, as the setting would say "always".
^^^ This all works pretty great!
However, the missing piece is vtsls notifying the client of its "internal" updates to the configuration, so that these configurations can be persisted, and provided on subsequent sessions. In the current state, if we restart the langauge server, it will not have configuration set, and will again prompt on the first run, which is not a great experience.
There seems to be no support that I can find in the spec for a server sending a client an update to configuration, so I'm proposing this as a workaround:
vtsls defines a custom $ notification, which is supported by the spec, to tell the client that configuration has been updated. Something like $/configurationUpdated, with a body LSPAny that contains the updated configuration key-value pairs.
When vtsls updates its internal configuration shim, it sends a $/configurationUpdated notification to the client with the changes.
The client can persist these changes, and then provide them on subsequent server restarts
let me know what you think!
The text was updated successfully, but these errors were encountered:
Hello! I've been testing out the
workspace/didRenameFiles
notification using vtsls and seem to mostly understand how to get it working. It required:workspace/didRenameFiles
notificationwindow/showMessageRequest
, if it has not provided a configuration setting for[javascript/typescript].updateImportsOnFileMove.enabled
. The request will look something like this:window/showMessageRequest
- in this example, let's assume they respond withworkspace/applyEdit
requestworkspace/didRenameFiles
, vscode reads the configuration setting from vtsls's shim service and (potentially - in the case of 'always' or 'never' being previously selected) does not sendwindow/showMessageRequest
- in this example, it would automatically go ahead and sendworkspace/applyEdit
request to apply the updates to imports, as the setting would say "always".^^^ This all works pretty great!
However, the missing piece is vtsls notifying the client of its "internal" updates to the configuration, so that these configurations can be persisted, and provided on subsequent sessions. In the current state, if we restart the langauge server, it will not have configuration set, and will again prompt on the first run, which is not a great experience.
There seems to be no support that I can find in the spec for a server sending a client an update to configuration, so I'm proposing this as a workaround:
$/configurationUpdated
, with a bodyLSPAny
that contains the updated configuration key-value pairs.$/configurationUpdated
notification to the client with the changes.let me know what you think!
The text was updated successfully, but these errors were encountered: