How is this supposed to fit into the current language server protocol without any concept of application execution lifecycle? Something like "stopped" which is referenced

My understanding/assumption is that when the editor pauses in the debugger, it would send this request to the language server to get these ranges. With it, it would include the current execution point as an optimisation, since the language server can compute only the ranges up until this point.

note: I'm not proposing anything new here, this is simple adding an existing VS Code API to LSP.

I’m struggling to see what this is for. It seems more targeted at debuggers than language servers. Apologies if I’ve completely missed the point!

I think it is a little confusing because this is a feature for debugging that involves the language server. My understanding is that the goal is to allow the language server (which already has parsed ASTs for a language) to provide regions in a document and their expressions, such that the editors debugger could evaluate those expressions and show inline values as the debugger steps through them.

The original VS Code description is here:

microsoft/vscode#105690

https://code.visualstudio.com/updates/v1_56#_inline-values-by-default-for-some-languages

"With a new debugger extension API, it is now possible for language extensions to provide correct inline value support and we are enabling the Improved inline values feature by default."

So let's say you had the code:

This request allows the language server to return a range around foo that is one of the types described above (text, expression, variable). If it was text then the literal text in the InlineValue would be displayed. If an expression, the editor would evaluate it (via the debug adapter), and if a variable, the editor would look it up from the variables list provided by the debugger.