-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Support for workspace/inlayHint/refresh to ensure inlay hints are correctly shown in editors #13369
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
Comments
Hmm, we should already be sending a refresh notification once we have finished loading. |
I can confirm that rust-analyzer sends /refresh requests after the corresponding client capability is set, smth. like lsp_types::ClientCapabilities {
workspace: Some(lsp_types::WorkspaceClientCapabilities {
inlay_hint: Some(lsp_types::InlayHintWorkspaceClientCapabilities {
refresh_support: Some(true),
}),
// ... snip
}),
// ... snip
} rust-analyzer then sends multiple calls on server startup, and on every change to a file. I do not quite understand this behavior, honestly: any editors knows beforehand about the change to a file, then communicates the change to the language server and gets back the /refresh request from r-a. Modulo files in the same language server, any change to a file forces the editor to invalidate all opened files' hints — later /refresh does not bring any new information. Neither makes sense to me, what do I miss? |
Ye, maybe the refreshes we do on file changes aren't needed at all. The spec isn't really clear on that as usual |
I'm running into this too. It looks like rust-analyzer does send a
In this log, rust-analyzer refreshes semantic tokens and inlay hints after the "Roots Scanned" and "Fetching" progress reports, but before "Indexing" begins. My client responds to this event by requesting inlay hints, rust-analyzer responds with nil, and does not send another |
…eykril Do not send inlay hint refresh requests on file edits See #13369 (comment) Editor itself is able to invalidate hints after edits, and /refresh was sent after editor reports changes to the language server. This forces the editor to either query & invalidate the hints twice after every edit, or wait for /refresh to come before querying the hints. Both options are rather useless, so instead, send a request on server startup only: client editors do not know when the server actually starts up, this will help to query the initial hints after editor was open and the server was still starting up.
After I open a small project with the file shown on open in VSCode and do not touch anything, I see the following LSP queries: Rust Analyzer Language Server Trace output
which means rust-analyzer does send a Unfortunately, I still see no hints in VSCode, and neither does it send the
It feels like a bug in VSCode, not in rust-analyzer. |
I think with not visible they mean not focused (as in not rendering) but still open. It might be a VSCode bug, given they are handling inlay hints in an odd way in general. It waits a second or so with asking for inlay hints after you stopped typing(which is incredibly annoying), so it might just not query for them if the refresh doesn't make it in a certain time interval. |
Hey there folks, I hope you're all doing well. This issue is related to sublimelsp/LSP-rust-analyzer#80
In editors such as Sublime Text, inlay hints do not show up until an edit is made to a document. As Rafał has mentioned:
Please see related documentation for workspace/inlayHint/refresh here.
Would you please consider supporting this? 😄
Thanks in advance!
Fotis
The text was updated successfully, but these errors were encountered: