foldingRange: clarify the meaning of [] vs null responses

[hyangah]

According to the spec can return FoldingRange[] | null, but it does not explicitly mention whether [] (empty FoldingRange) and null are semantically distinct yet.

Empirically, I am guessing [] means there is no folding range (so editor may remove all existing folding ranges) while null translates into provideFoldingRanges returning null or undefined (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?

[dbaeumer]

In general null is always equal to []. There is currently no support in LSP that a server can say: I am busy and can't generate a result so please ask me later again. This would need to be expressed differently than using null

[hyangah]

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 error as a workaround if the language server cannot compute the complete folding range at the moment. Until the future LSP supports the "I am busy and can't generate a result" mode response. That may create noise to clients that treat every error as significant, but at least in the vscode node client, this doesn't seem too bad. Does this sound reasonable?

[rwols]

Would client-initiated progress reporting solve your problem of "I am busy and can't generate a result" ?

[hyangah]

@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. :-(

[dbaeumer]

Resolving this using an error is the right approach right now. We started to support Busy please ask again for semantic tokens by allowing returning a special cancel error response that will retrigger the computation.

[dbaeumer]

What you can do right now is the following:

• use the middle ware on the client to intercept the folding result range
• interpret the result
• retrigger the request if you know you server can handle it know
• return the result from the retrigger.

[hyangah]

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?

[dbaeumer]

@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