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
foldingRange: clarify the meaning of [] vs null responses #1200
Comments
In general |
Thanks! We are currently trying to deal with folding range info disappearing because the go language server returns a partial or an empty response as a result of temporary parsing issues. I am proposing to return an |
Would client-initiated progress reporting solve your problem of "I am busy and can't generate a result" ? |
@rwols In our case, "The source code is not in the state that I can work with yet. Next time after user edits more I may be able to participate in the folding range computation" may be more precise description of the condition. In case of VS Code, I see the client (vscode) issue folding range requests for almost every key stroke, so progress reporting doesn't seem like a good fit for it. :-( |
Resolving this using an error is the right approach right now. We started to support |
What you can do right now is the following:
|
Thanks @dbaeumer! The middleware approach is interesting - does it imply we (the extension) are responsible to hold the request until we have the correct answer? In our specific case, knowing whether the server is ready to handle the request is hard because the root cause is not the overload. The code is in a state where the server can't work with nicely. The only possible resolution now is the user edits the code. I observed that VS Code keep issuing foldingRange requests as the user edits the code. I didn't try, but if the middleware holds the request for retry, I am guessing VS Code would cancel the previous outstanding foldingRange request before sending another foldingRange request for the new version of the code. If that's the case, isn't the middleware logic for hold&retrigger redundant? |
@hyangah yes, VS Code (and all other LSP clients should) cancels a request for which the result is not needed anymore. If your server can handle that correctly you don't need to have a middleware. However you can in the middleware detect if the request is canceled as well and react accordingly |
When parse errors occur, go's parse package cannot recover nicely. gopls tried to compute folding ranges based on the partial info in this case, but returning partial folding range info confuses editors (vscode) and results in dropping previous folding range info from the region after the parse error location. This CL makes gopls not to return anything - so the editor can tell the result is not believable and ignore it. The ideal solution is to return a response explicitly surfacing this case, but currently LSP (3.16, as of today) does not have a way to describe this condition. See the discussion in microsoft/language-server-protocol#1200. We also tried to make gopls return an error. While it worked nicely in VSCode, we are not sure about how other editors handle errors from foldingRange. So, instead, we just let gopls return an empty result - since foldingRange is already broken in this case, we hope it doesn't add a lot of noise to existing users. VSCode Go will check the response from the middleware. If the response is empty but the file is not empty, VSCode Go will ignore the response. (https://go-review.googlesource.com/c/vscode-go/+/299569) Updates golang/vscode-go#1224 Updates golang/go#41281 Change-Id: I917d6667508aabbca1906137eb5e21a97a6cfdaf Reviewed-on: https://go-review.googlesource.com/c/tools/+/291569 Trust: Hyang-Ah Hana Kim <hyangah@gmail.com> Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com> gopls-CI: kokoro <noreply+kokoro@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Rebecca Stambler <rstambler@golang.org>
According to the spec can return
FoldingRange[] | null
, but it does not explicitly mention whether[]
(empty FoldingRange) andnull
are semantically distinct yet.Empirically, I am guessing
[]
means there is no folding range (so editor may remove all existing folding ranges) whilenull
translates into provideFoldingRanges returningnull
orundefined
(so editor will not use the info from the language server) . It would be nice if the spec explicitly clarifies the semantic differences.And, VS Code question while we are here: if a language server responds with 'null' or an error, what does VS Code do - remove all the folding ranges from the previous responses, or keep the folding range info from the previous successful, non-null response until the next successful response is received?
The text was updated successfully, but these errors were encountered: