-
Notifications
You must be signed in to change notification settings - Fork 5
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
migrate to metals-goto-location to window/showDocument #164
Comments
Custom command contains additional field Interface is almost 1:1 same (uri == uri, range == selection) so without this 'other-window' flag migration could be instant. |
I didn't know that |
Thanks for a link to this specific commit 👍 probably adding |
I am not sure otherWindow is needed in LSP. We create either WebView with links to commands or code lenses with commands. So in reality it's not the server invoking the command, but the client itself. Having it in LSP spec doesn't really help us, we still need to invoke commands on the client side. |
I think it's the other way around:
so clients are expected to implement a UI for that or invoke external program if the request has |
@laughedelic It will help us in some scenarios, but I haven't clarified that I was talking about the analyze stacktrace command. For that command we create a new document or webview, which users can use to navigate over the code. And that document already contains either links to commands or commands in code lenses, which clients need to know how to invoke. And that is the only part of Metals that uses |
Anyway I added an issue in the repo to discuss it: microsoft/language-server-protocol#1140 |
It seems that actually the idea was included in the spec: There is an option to use |
LSP Spec 3.16 defines Show Document Request
It would be nice for Metals to migrate the custom
metals-goto-location
to this new standard request to avoid custom client implementations.Search terms
LSP, spec, show document
The text was updated successfully, but these errors were encountered: