Pull diagnostics API in Visual Studio Code

[GerardSmit]

I'm developing an extension for C# WebForms, which is basically an embedded language in HTML. I've created a language server which handles the WebForms language and redirects other ranges to the CSS and JavaScript language server through virtual documents. In the docs, this is called "Request Forwarding": https://code.visualstudio.com/api/language-extensions/embedded-languages#request-forwarding.

Everything works, except one thing: diagnostics.

In the docs it's stated that this will be supported in LSP 3.17, which is now released with the new pull diagnostics messages:

• https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocument_diagnostic
• https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#workspace_diagnostic

But there is currently no way to get the diagnostics of a virtual document, other than opening the file.

With other API's (for example fetching code completions) we can use commands like vscode.executeCompletionItemProvider:

https://github.com/microsoft/vscode-extension-samples/blob/d7c486e9c07f91407aed982e16c3839bfa0cefdc/lsp-embedded-request-forwarding/client/src/extension.ts#L60-L65

So I would like a new command that fetches the diagnostics: vscode.executePullTextDocumentDiagnostics with the URI as parameter.

---

With an ugly workaround it's possible to fetch diagnostics. I'm opening the text document and then fetching the diagnostics:

vscode.workspace.openTextDocument(virtualUri).then(doc => {
    vscode.window.showTextDocument(doc, { preserveFocus: false }).then(editor => {
        client.diagnostics.set(uri, getDiagnostics(uri));
        return vscode.commands.executeCommand('workbench.action.closeActiveEditor');
    });
});

The problem is that:

1. You see the virtual document being opened.
2. You see duplicate diagnostics (from the actual file and virtual file):
   

[jrieken]

We have no plans to implement a pull diagnostics API for VS Code. For once we don't want to "compete" with the existing push API and more importantly we don't know when to pull for what. Extensions have no means to express inter-file dependencies that would allow us to do qualified "pulling". There it is up to extensions to do this.

redirects other ranges to the CSS and JavaScript language server through virtual documents. In the docs, this is called "Request Forwarding"

This approach isn't suitable when want you to do validation (btw also when having the ability to pull for diagnostics) because it happens without context. A library integration should be used instead

[GerardSmit]

This means that the comment by @aeschli in microsoft/vscode-extension-samples#430 (comment) will never be implemented?

Once LSP 3.17 is shipped, we need an equivalent vscode diagnostics provider APIs and we need to update our language extensions (in particular css and TypeScript) to adopt it.

And the docs change in microsoft/vscode-docs@e885ed2 have no meaning at all? If I would've known that this would never be implemented, I wouldn't have chosen for this path.

For once we don't want to "compete" with the existing push API and more importantly we don't know when to pull for what.

We already have multiple execute* commands that gets information based on the file extension (https://code.visualstudio.com/api/references/commands#commands), for example vscode.executeCompletionItemProvider.

[aeschli]

LSP now has diagnostic pulling and it got adopted by several language servers (JSON / CSS / HTML) a while back and is in use.
I think it should be adopted in the VS Code API

• LSP clients can profit
• allow programmatic pulling of diagnostic, e.g. useful for embedded language (admittedly only for simple cases)
• simplify our story, including our documentation (see Incorrect "Request forwarding" conclusion about diagnostics vscode-docs#5778)

@jrieken Check out the protocol that @dbaeumer came up with. There's no need for the client to understand the cross-file dependencies

• servers can signal that new pulling is needed
• pulling happens in two levels, document / workspace
  • document diagnostics for fast and frequent editor diagnostic requests
  • workspace diagnostics for the entries in the problems view, which can take as longer

[GerardSmit]

Should this issue be re-opened or is there an issue open that tracks the API?

[zachallaun]

The Embedded Programming Languages guide still includes the following reference to this issue:

Request forwarding:
...

• - Does not yet work with diagnostics errors. The VS Code API currently does not support diagnostic providers that can 'pull' (request) diagnostics. (Issue).

The phrase "currently does not support" suggests that VS Code will eventually support diagnostic pulling, but this issue suggests otherwise. As mentioned in the comment before me, should this issue be re-opened or should the docs be updated to reflect that this feature is not planned?

[GerardSmit]

@zachallaun I think it's better to create a new issue. After my comment on 2022 Sep 5, I never received any comments, so I made a new issue on 2022 Nov 10 which received feedback. And my new comment on 2022 Nov 21 never got feedback. I'm not sure if the vscode team gets notifications of closed issues or they aren't being triaged 🥲.

[jrieken]

Please do not create a new issue. We are reading notifications for *out-of-scope issues, users can still vote on them, but not every interaction leads to an action here.

The phrase "currently does not support" suggests that VS Code will eventually support diagnostic pulling, but this issue suggests otherwise.

@zachallaun you are correct can you please file an issue against vscode-doc so that this gets updated

[MihaelIsaev]

Would be great to have it as mentioned in #66982