`workspace/textDocumentContent`: expand with languageId

[rwols]

The workspace/textDocumentContent client->server request is great. It generalizes many bespoke solutions:

• java/classFileContent from jdtls (returns Java content)
• deno/virtualTextDocument from deno (returns TypeScript content)
• jumpToSchema command from yaml-language-server (returns YAML content)
• roslyn-source-generated URI schemes from roslyn-language-server

But, while workspace/textDocumentContent is a general solution for handling these URIs, the client cannot know what syntax to apply to the received content.

I propose to let servers send a languageId field along in the response to a workspace/textDocumentContent response. This way clients can find a syntax to apply to the content.

Proposal

In the TextDocumentContentResult type, add a new field:

/**
 * Result of the `workspace/textDocumentContent` request.
 *
 * @since 3.x.0
 */
export interface TextDocumentContentResult {
	/**
	 * The text content of the text document. Please note, that the content of
	 * any subsequent open notifications for the text document might differ
	 * from the returned content due to whitespace and line ending
	 * normalizations done on the client
	 */
	text: string;

	/**
	 * The text document's language identifier.
	 */
	languageId?: string;
}

Notes

• Because the TextDocumentContentResult type now exists, we have to make languageId an optional field.
• There doesn't seem to be either a client capability or server capability needed. If the server supports it, it just sends along the languageId. If the client supports it, it will interpret the languageId field. If a client supports it, but a server doesn't, then a client has to account for that possibility.
• In Sublime Text LSP, we currently solve the problem of what syntax to apply to the content by requiring a little bit of config. But this can be fully automated I believe.

[jwortmann]

This was discussed and rejected before, when this feature got added; see #1994 (comment) and subsequent comments:

Even if a language server provides a content, it might not be the one providing the language id and its smarts. This is why the client decides on the language id and it is open in the spec how a client does this. VS Code has a registery to register language ids and uses AI (a language model) to determine the language id based on content.

It is very likely the extension that manages the language server that does that registration. Other clients might have other means to do that registration. This is why it is left up to the client.

But the server does already know the language of the content it provides, and could easily pass it along with the content to the client. I think there shouldn't be the assumption that all clients would have either built-in AI for that, or an "extension that manages the language server", or other means that don't require manual configuration.

---

Edit: I removed the sarcasm from my last sentence, sorry if that sounded rude before. But my point is, I already brought up this exact concern when this feature was added to the specs, and it seems that on purpose it was left to decide for the client. Which, in my opinion, was a mistake, and I also don't really get the argument from the first sentence that I quoted above:

Even if a language server provides a content, it might not be the one providing the language id and its smarts.

I think in practice it is unlikely that a different server handles the "virtual" text documents generated by another server, and even if that is the case, I don't see why it should be a reason to not allow the server to decide the language id.