`workspace/textDocumentContent`: expand with languageId

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.

Start with the TextDocumentContentResult definition in the LSP 3.18 specification and trace how workspace/textDocumentContent responses are represented. Done means the optional languageId field is documented consistently with the proposal and the surrounding protocol definitions remain coherent.