Explore built-in "variable explorer" notebook functionality

[roblourens]

The Jupyter extension has a variable explorer as a webview in a panel. This should be moved into vscode core as part of common workbench UI. Things to explore:

• The Jupyter extension creates a "fake" debug session to show variables in the debug UI
• Show variables inline in the cell editor, similar to debug inline values. Possibly even without a separate variables view
• Show variables on hover, same as debugging
• Show a separate tree/table view, similar to current experience
  • Odd duplication with debug variables view. Could be that you just have the same data visible in two places. Maybe the debug variables view hides when debugging a notebook.
• Show variables in the Debug viewlet, driven by new variable provider API when not debugging. This would be a new type of "debug session" for inspecting variables only, is managed by vscode, can't be terminated by the user, somehow gets upgraded to a real debug session when the notebook is debugged

[roblourens]

Request for showing the same data that the variables viewer shows in extra columns, but in normal debugging: #146748

[roblourens]

Some notes from conversation with @DonJayamanne

• I think we both agree that a tree is a better way to view variable data than a table with non-expandable rows
• Enable extensions to contribute actions to open different viewers on variable rows
• How important is it to show the size and type at the top level, like currently?
  • Seems that it would be ok to show those attributes on hover
  • But in a tree view, we could still show them up front and include them next to the value
• A tree would lose the ability to sort variables by name/size/type/value, but this doesn't seem important
• Can we get away with only showing variables using inline values/hover?
  • Many users do not use a variable explorer, and inspect variables by running code
  • On the other hand, they may be used to seeing a list of variables, and just want to see their familiar list
  • We have had a list of variables in vscode for quite awhile, could be an adjustment to remove it
  • And users may want to look at the value of a variable while not next to code that uses that variable. esp in long cells

[roblourens]

Hi @davidanthoff @jonsequitur @claudiaregio, I wanted to call this out to you that we have started to investigate how to add a built-in variable explorer with API that notebook extensions can drive. For Jupyter, this would replace the variables viewer that we currently have. I've written some thoughts on the UI experience at the top of this issue, and #166296 covers API.

Is this something that you would be interested in using? If so, what would you like to see in it?

[jonsequitur]

We'd definitely be interested in using it for Polyglot Notebooks.

One of most important distinctions we have is the need to say which subkernel a variable is located in:

Enable extensions to contribute actions to open different viewers on variable rows

Notice in the screenshot that we have an action button for sharing variables with other kernels. This doesn't open a viewer. It adds a cell with generated code:

I think we both agree that a tree is a better way to view variable data than a table with non-expandable rows

Agreed. For this reason, we're working on making our inline object displays into expandable trees similar to what we do for JSON:

[jonsequitur]

I don't see it mentioned here but when would the variables in this view be refreshed? Our current implementation is a bit chattier than necessary and we're thinking through how to improve that.

[roblourens]

One of most important distinctions we have is the need to say which subkernel a variable is located in:

Is it important that this data be immediately visible for every variable? What if you could see this info by hovering, or expanding the variable value?

we have an action button for sharing variables with other kernels

I'm imagining that extensions will be able to contribute arbitrary commands, the same way other menu contributions work.

when would the variables in this view be refreshed

That will likely be up to the extension

[jonsequitur]

One of most important distinctions we have is the need to say which subkernel a variable is located in:

Is it important that this data be immediately visible for every variable? What if you could see this info by hovering, or expanding the variable value?

Yes, I think this is critical to help people understand polyglot workflows and variable sharing.

[roblourens]

I'm imagining that as a shortcut, maybe the extension could return the kernel name as part of the variable name. e.g., it returns "name": "varname [pwsh]", do you think that would suffice? Does your table support sorting by kernel, and is that important?

Can you also tell me about the behavior of the filter box?

[jonsequitur]

The column header helps people understand what's in the column, so concatenating them would be less intuitive.

Another thing that would be very useful is a type name column. Our inline output always renders types with a link to documentation, and having that facility would be very helpful here as well.

Given these two considerations, the ability to add custom columns seems like it would let us bring our own specific scenarios as appropriate.

Sorting by kernel would be helpful. We don't currently support sorting.

The filter box currently filters across the string values in all columns, so you can use it to filter by kernel name or variable name or values.