[Request] [Notebooks] Allow arbitrary values in a cell's language selector.

.NET Interactive notebooks allows different cell languages via the language selector in the bottom right of the cell. Currently the only allowable values are languages that have been pre-registered with VS Code via the "contributes"."languages" field of the manifest.

A common scenario we’re seeing is the user creating multiple connections to different SQL databases, e.g., AdventureWorks and Northwind. Currently we handle this awkwardly by pre-registering a language dotnet-interactive.sql with an alias of “SQL (.NET Interactive)”, but that doesn’t actually let the user execute a query against a specific database connection. They have to put a magic command at the top of the cell that we use to route the request.

For example, one cell might have the language set to “SQL (.NET Interactive)”, but the contents of the cell look like this:

#!sql-AdventureWorks
SELECT * FROM ...

and the next cell also has it’s language set as “SQL (.NET Interactive)”, but its contents are:

#!sql-Northwind
SELECT * FROM ...

It would be much more instructive to the user if they could simply select from the dropdown “C# (.NET Interactive)”, “F# (.NET Interactive)”, “AdventureWorks”, “Northwind”, etc., where the last two items we dynamically added at runtime.

[roblourens]

I think we will be discussing this tomorrow morning, but I’ll give you my initial reaction - it seems like you are mixing two concepts- language and where the code will execute. Any reason you can’t leave the language picker alone but use a NotebookCellStatusBarItemProvider to provide another item right next to it that shows the target options available based on the cell’s language? It seems like these two concepts are independent and we shouldn’t be making fake languages for the matrix of combinations.

[brettfo]

As I’ve discussed this idea with my team we’ve narrowed the ask a bit.

A notebook controller has the supportedLanguages property of type string[] | undefined. Those string values are then matched against languages registered with VS Code and at runtime the dropdown displays the “friendly” names. E.g., setting that property to ['dotnet-interactive.csharp', 'dotnet-interactive.fsharp'] will result in the values “C# (.NET Interactive)” and “F# (.NET Interactive)” being visible in the dropdown.

The Ask

We propose that the supportedLanguages property type be expanded to string[] | { languageId: string, displayName?: string }[] | undefined where the displayName? property, if present, will be used at runtime and if not present then the default value of the registered language’s “friendly” name will be used.

The Result

In a .NET Interactive Notebook with multiple SQL connections, the user dropdown will display the name of the database connection.

Example

notebookController.supportedLanguages = [
    { languageId: 'dotnet-interactive.csharp' },
    { languageId: 'dotnet-interactive.fsharp' },
    // ...all the other values normally present
    { languageId: 'dotnet-interactive.sql', displayName: 'AdventureWorks (SQL Server 2018 - localhost)' },
    { languageId: 'dotnet-interactive.sql', displayName: 'Northwind (SQL Server 2008 - Azure)' },
];

N.b., the last 2 entries both list dotnet-interactive.sql as the language id, and that is so the proper TextMate grammar can be selected, but the displayName? property is different so the user can differentiate between them.

At this point the .NET Interactive extension can get the cell’s selected language identifier, e.g., something like this:

// this API should come from VS Code
getCellLanguageValue(cell: NotebookCell): string | { languageId: string, displayName?: string } {
    ...
}

// this code is in the .NET Interactive extension
const cellLanguage = getCellLanguageValue(theCell);
if (typeof cellLanguage === 'string') {
    // we do our own mapping from `dotnet-interactive.csharp` to `C#`, etc.
} else if (typeof cellLanguage.languageId === 'string' && typeof cellLanguage.displayName === 'string') {
    // now we map against the cell's reported language as well as its display name
} ... // all other scenarios