-
Notifications
You must be signed in to change notification settings - Fork 167
Use diagnostic range when requesting getCodeFixes
#885
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
I would say that this IS the responsibility of the client, though I can't see it stated explicitly in the LSP specification. But this is how it works in VSCode's client (it's not the Clients can handle it by expanding the range to account for diagnostics that overlap the current point (or range). |
Wait, the link I sent above is from That's exactly why I thought this should be a typescript-language-server responsibility. If generic clients adjust their range like this for all servers, they're going to end up pulling in additional code actions that don't actually make sense for the user's current selection (an example being tsserver returning "surround" code actions when you have a selection > 0 width. |
EDIT: I see where sublime adjusts the range now. However, I'm still curious about your thoughts on the vscode behavior. https://github.com/sublimelsp/LSP/blob/d4538fa34ff689672ec60ab8f585b3cb4c828f49/plugin/documents.py#L278
|
Hmm, you might be right that this should be the responsibility of this server. But also VSCode's implementation requests code actions separately for each passed diagnostic rather than bundling them all in a single request like |
I noticed a discrepancy between vscode (tsserver directly) and typescript-language-server.
Given the files:
We will receive a diagnostic over

Link
inApp.tsx
:When placing the cursor after the
k
inLink
inApp.tsx
, vscode makes agetCodeFixes
request that appears as follows:As you can see, the requested start and end positions are the range of the diagnostic:
And as such, a code fix to import
Link
is returned from tsserver.This is because vscode's implementation uses the diagnostic's range as the range: https://github.com/microsoft/vscode/blob/fd4b93963e6456d09175410ea1cc84cb796ad241/extensions/typescript-language-features/src/languageFeatures/quickFix.ts#L330
Compare this with
typescript-language-server
, which requests the following:As you can see the requested start and end positions are simply from the cursor position and thus tsserver returns no results:
Now, it could be argued that this bug is instead on tsserver to include the trailing position in
getCodeFixes
range, such that a request from 7:12-7:12 would still receive the fix. But I think this could be an opportunity to updatetypescript-language-server
to adjust its request range instead.I don't think this is something the client can handle - as if the client sent the range of the diagnostic as its range, it would be misrepresenting the current editor selection, and potentially receive other invalid code actions.
Thanks for your consideration!
The text was updated successfully, but these errors were encountered: