Open mjbvz opened 3 years ago
https://github.com/microsoft/vscode/issues/117812 shows another case where a different API could help us ship a better user experience. Right now, you have to wait a moment to get fixes after you introduce an error in a file
Might also refactor?
Updated URL for the LSP link in the issue body: https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocument_codeAction
@navya9singh @DanielRosenwasser just an update - on the VS Code extension side of things, @mjbvz and I have added a fix to handle the issue when there are pending diagnostics at the point of re-requesting code actions https://github.com/microsoft/vscode/issues/117812
this is currently in our latest insiders, but lmk if this leads to any issues with the changes in the API, or when those changes land!
Follow up on #27614
Search terms
getCodeFixes
getSupportedCodeFixes
Problem
The
getCodeFixes
API currently takes a range plus a diagnostic code. Currently, the range we pass to it has to match the range of the diagnostic we are trying to fix. This API is difficult for editors to implement for a few reasons:Proposal
We should consider a new quick fix API that addresses these problems and also is better aligned with the language server protocol. My proposal is that instead of having to think about diagnostics, editors pass the TS Server a range and are returned the valid quick fixes in that range.
Here's what the VS Code api for this looks like:
https://github.com/microsoft/vscode/blob/9a21b536639c2d986c50fb51b7da67bafdb50c9b/src/vs/vscode.d.ts#L2336
And here's the LSP:
https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocument_codeAction