Language service use of a whole notebook as single (concat) document

[jrieken]

Develop an end-to-end sample that maps many cells to a single LS document, e.g have single concat document for a notebook that re-uses TypeScript features and/or features from a language service (LSP)

[jrieken]

The joh/concat-branch has some changes that do the following

• a ConcatDocument is also a TextDocument, and
• concat documents appear as normal text documents, e.g are part of workspace.textDocument or onDidOpen/Close events etc
• an extension registers language providers for notebook-cells but then "redirects" requests onto the concat document.

The snippet below does that for the definition provider. A request for a notebook cell is translated into a request for the concat document. Then executeCommand is being used to get the actual language service involved and finally the results is translated back.

const cellSelector = { language: 'css', scheme: 'vscode-notebook-cell', exclusive: true };

vscode.languages.registerDefinitionProvider(cellSelector, new class implements vscode.DefinitionProvider {
	async provideDefinition(document: vscode.TextDocument, position: vscode.Position, token: vscode.CancellationToken) {
		if (!notebook.cells.find(cell => cell.uri.toString() === document.uri.toString())) {
			console.log('NOPE')
			return;
		}
		const pos = concatDoc.positionAt(new vscode.Location(document.uri, position)); // translate: cell -> concat
		const result = await vscode.commands.executeCommand<vscode.Location[]>('vscode.executeDefinitionProvider', concatDoc.uri, pos);
		return result && result.map(loc => concatDoc.locationAt(loc.range)); // translate: concat -> cell
	}
});

• 👍 This works! Variables defined in one CSS cell appear in other cells and thereby enable go-to-def, suggest etc
• 👎 Because CSS already works for individual notebook cells, duplication of results is happening, e.g there are results based on cells and results based on the concat document. The current "solution" is to register providers as exclusive - something that we cannot make generally available.
• 👎 This only works because CSS is already able to digest documents from arbitrary schemes and the added value is the introduction of symbols (variable defined in another cell). However, experience has shown that digesting arbitrary sources is hard, e.g TypeScript isn't as good as CSS
• 👎 This does require an extension that enables these languages features (e.g the snippet above) and isn't something that just works out of the box
• 👎 There are some hacks in the current exploration that need careful engineering, e.g currently the concat document only lives on the extension host side but must also exists in the renderer for language features to work.

[jrieken]

Closing as the "a concat doc is a normal doc" approach didn't work so well (see above). We will add a language service guide for notebooks