Builtin interactive window support

[rebornix]

Explore how to replace the webview interactive in Jupyter extension with a built in one with better workbench integration and leverage the existing notebook ecosystem.

Prototype

• Core
  • ctrl+enter on the code editor widget as a command/kb: interacive.execute
    • execute, get active text editor, get the content, find the notebook document, apply worksapce edit
    • request execution on cell notebook.cell.execute (argument is CellRange)
  • Make this document readonly
  • setting interactive.experiments.enable
  • Swap menu ids for interactive editor (notebook/toolbar to interactive/toolbar)
• Jupyter
  • register controllers for interactive
  • contribute commands/codelens when config.interactive.experiments.enableBuiltinEditor == true
  • remove decorations for cell editors in the interactive window
  • when a controller is selected by the document, then insert a markdown cell
  • collapse all cell inputs by default

Snapshot of how it looks integrated together:

Issues unveiled from prototype:

• Affinity doesn't always work, might be caused by no activeNotebokkEditorChange event.
• register intellisense for input editor. This would require some rewrite as it will need to read the NotebookDocument in the IW.
• Variables View is global and depends on activeNotebook
• Initial kernel/sys info: in traditional interactive window / repl, when the window/repl is started, there is a printed message about the environment (e.g., Python 3.8, balabal). The info is only known after the underling jupyter kernel is started, so if users open Interactive Window first, and shift+enter to execute code from the input editor, we insert a code cell first before the kernel gets a change to print the kernel info.

Backlog

• Core

  • Customized theme tokens for notebook in the interactive window
  • Improve styles for input editor in interactive window
  • Clearer UI indication that interactive window is readonly (e.g. cell editor background color, no drag and drop feedback)
  • Collapsed cell input for code cells submitted from a script file, with just the first line of code shown

• Jupyter

  • Implement variables view
  • Interactive window multiple, single, perFile settings
  • Preserve #%% comments in cell metadata and restore during export
  • IPyWidgets support
  • Merge exporting to notebook with existing quickpick
  • Debug cell
  • Support executing markdown cells from a script file in the interactive window
  • Support exporting markdown cells from interactive window (preserving language, cell type etc)
  • Add a setting to export to Python script without preserving cell delimiters
  • Suppress language server intellisense for TextDocuments in embedded NotebookDocuments (handled by the core)

[rebornix]

Workflows

The interactive window is accessible in multiple way, e.g., invoked from command palette, codelens from python files, invoked by Jupyter extension through commands, etc. Each of them has different requirements for the UX and API, which are not fulfilled yet by existing notebook api.

Command Palette

Users can create an Interactive Window from command palette or keyboard shortcuts. The core will leave the controller/kernel selection blank or use the last picked controller/kernel. If there is no cache for last picked controller, extensions can set controller affinity to control which controller should have higher priority than others. The behavior should be the same as Notebook Editor so there is no requirement for API.

UX wise, we should explore how to make controller switching easy enough

Codelens/commands

Users can send code snippets from python files to the interactive window by codelens for # %%. The execution request can be sent to existing interactive window or new interactive window. Since the language of the code snippet is already known, we need to support specifying preferred controller/kernel for the newly created interactive window. Users don't have to choose a kernel after the interactive window is opened

[rebornix]

Current status of the builtin interactive window support in Jupyter:

• Users can open an interactive window through command "Jupyter: Create Interactive Window"
• Users can open an iw through codelens from a python file snippet (wrapped by # %%)
• Users can execute code
• Auto suggestions for the input editor in the interactive window

Rollout plan

The builtin interactive window is now only accessible to the Jupyter extension (users create iw through Jupyter commands) and it's shipped with Jupyter in VS Code Insiders, behind a setting (by default it's false). The intellisense support is part of the Python extension so to roll out this feature, we depend on when Python ships the changes.

• We will first turn on these features for Python users in Insider daily channel next week.
• We will turn on for Python users on VS Code Insiders in Insider daily/week channels once it's shipped with weekly.
• Based on the feedbacks we collect next week, we can decide if we want to have it on for users on VS Code stable.
• Once Python ships the language support to their stable channel, we can turn on for all VS Code Insiders users.
• Last step is turning on this feature for all users using native notebook.

Follow ups

Currently the interactive window is created and managed by api commands and notebook/text document events. We will need to move them to a proper API since we already learnt what we needed for managing interactive window.

We will also look into the backlog items listed above.

[isidorn]

@rebornix just did a nice demo for me, and here's some ideas that came up in the meeting:

• Should the interactive window instead be in the panel or sidebar. If we move it to the panel or sidebar it would be easier to understand that it is a supplement to the main notebook editor
• I believe moving it to a sidebar or panel would give a better default layout for most users. And like Terminals we should allow users to drag and drop it into the editor area for more space
• We can introduce some smart context keys, and use them for visibility of views. So that in practice the interactive window would actually replace the debug console (debug console would get hidden when context key is true, and interactive window would be visible)
• We should reuse the debug console input editor since this component seems to be 100% the same Interactive window and debug console should use same widget for input #127498

Here are some points that we touched upon for the jupyter variables:

• The notebook variable view should be architected similar to the debug variables view - the vscode core controls the table / tree and extensions are actually data providers. That way we can have a nice consistent look and feel across different notebook kernels, and there would not be multiple contributed views
• We can also use smart context keys in such a way that the regular debug variables view gets hidden, and the notebook variables view takes its place.

Doing the two above would make the interactive notebooks and notebook variables behave like concepts in VS Code which the users area already aware of and they would not feel alien. Since the interactive notebooks would be similar to the debug console and the notebook variables similar to the debug variables view.

[joyceerhl]

it is a supplement to the main notebook editor

This is not necessarily the case. The interactive window is used for iteratively developing Python scripts. Case in point: over 70% of interactive window users do not use Jupyter notebooks in VS Code at all.

the interactive window would actually replace the debug console

This is what we'd eventually like to have happen as well. The interactive window is ultimately a debug console with the ability to display richer outputs. /cc @rchiodo @greazer

reuse the debug console input editor

Yes, this would be great. It would also solve an important problem that we currently have, where users are allowed to enter text into the interactive window input editor even when the underlying kernel session has not started. In the debug console, you cannot enter any code into the debug console input editor if no debug session is running. The interactive window input editor should inherit this same behavior:

[greazer]

Should the interactive window instead be in the panel or sidebar. If we move it to the panel or sidebar it would be easier to understand that it is a supplement to the main notebook editor

Per what @joycerhl says above, the IW was not originally intended to be a supplement to the main notebook editor. The original and desired intent for the IW is to be an alternate form of creating and editing a script that in the end, is treated and worked with much like a notebook. There are many users who prefer to use a cell-marked script in combination with the IW to do the exact same tasks they'd do with a notebook, but find the usability and capabilities of the workflow to be superior to that of notebooks. This is particularly true of people with some level of software engineering background. Feel free to watch this most excellent talk by Joel Grus to gain some background as to some of the reasons we first pursued the IW model: https://youtu.be/7jiPeIFXb6U.

That being said, there IS a case for using an IW with a regular notebook. In this case the IW can act like a scratch-pad of sorts to dabble with code before copying a block of it to a cell. This model has not been fully fleshed out any more than a prototype.

As for making it a sidebar, the main problem lies in the fact that we have added support for having multiple IW's open based on significant user feedback to support different use-cases. See the "Jupyter: Interactive Window Mode" setting for details.

We can introduce some smart context keys, and use them for visibility of views. So that in practice the interactive window would actually replace the debug console (debug console would get hidden when context key is true, and interactive window would be visible)

This seems like an interesting idea and perhaps plausible, but first, I don't think we're going to go down the panel path, but even if we did, I'm worried there's some differences between the two windows in the way they treat output. Of course we could make them identical, but I'm not sure they currently are.

We should reuse the debug console input editor since this component seems to be 100% the same Interactive window and debug console should use same widget for input #127498

I think this is ok to try, but honestly, I have personally often thought the debug input box was just too small (height-wise). To me it feels cramped even if it does support multi-line inputs. Also, it's pretty undiscoverable. I remember not even noticing it was there for a while. Note that there is one big difference between the two. The debug input box treats as a submission. The interactive window treats it as a new-line. Likewise shift-enter is opposite. This is yet another problem regarding swapping the IW for the debug panel, btw.

Doing the two above would make the interactive notebooks and notebook variables behave like concepts in VS Code which the users area already aware of and they would not feel alien. Since the interactive notebooks would be similar to the debug console and the notebook variables similar to the debug variables view.

Love this idea! If only we were able to make this happen when were were an extension living on our own!

[isidorn]

@joyceerhl great, so let's continue the discussion for reusing the debug console input #127498
Also because 70% of users might use the interactive window and no notebooks does not mean the interactive window should by default be in the editor. Most REPL experiences I know are usually at the bottom with a lot of horizontal space, that's why I think that would also be a natural fit for the interactive window.

@greazer multiple IW windows: I would suggest to first start simple and we polish the experience for one window, once we are happy with that we can easily expand it to multiple windows. Also as an example: Terminal is in the panel and we support multiple terminals. Do users want to look at two interactive windows side by side?

As for your debug input comments:

• too small: we can change the height easily if we decide this is the things to do
• enter vs shift enter: this is user configurable already

But the point regarding both: is that they should just look and feel consistent. Once a user is used to the debug console she should be able to easily use the interactive window, and not think hard about what is shift+enter and what is enter.
Consistency is the key here imho, and reusing components would help here.

Also I agree with @joyceerhl that the interactive window is ultimately a debug console with the ability to display richer outputs. So our longer term goal is to have a common component where clients could ideally register their viewers: the debug console would use the tree as a viewer and the IW would register richer outputs.

[IanMatthewHuff]

Just putting in a comment here to say that I'm very pro the variable view moving to the vscode control for all notebook scenarios. Current control always feels out of place and it's even more so now that notebook debugging support is coming online and shows variables in the vscode variable view.

[greazer]

@isidorn, I understand about polishing a simple scenario first, and even experimenting with the IW as a panel. However, IIRC there was nothing stopping us at the beginning to implement it as a panel and I'm quite sure we considered it.

A couple other reasons I can think of beyond supporting the multiple scenario are:

• The IW often will have large plots and other images that do not present themselves very well horizontally. It's use case isn't really the same as a traditional REPL.
• If the IW is a panel, the size of the outputs will likely cause the user to have to resize the panel itself. If I'm not mistaken, this will cause other windows that are part of the same panel to have to be resized likewise, taking up space those other windows don't make good use of.

Also, I strongly agree that we should maintain consistency of experience where it makes sense. In this case, I'm not totally convinced that the IW is just another debug console. I could be convinced, but I need to see some use cases.

@IanMatthewHuff, yes as long as the variable view doesn't have to come with the rest of the debugger windows, like callstack and breakpoints.

[greazer]

Finally one other thought I had that is somewhat of a hybrid between a panel and an editor would be to support a single editor tab that has a panel "attached" to it. So each editor instance could have it's own panel that is resized or possibly even repositioned in a way that makes sense for whatever the user is doing in the associated notebook/script. Obviously, this is something that would be very different than what VS Code has supported in the past and would really needs some analysis. :)

[rebornix]

In current interactive window, the input editor is at located at the bottom of the editor control and we currently only show one line of text by default when it's empty:

It somewhat aligns with the input editor in Debug Console but since the interactive window is rendered in editor groups, whose height is usually large, it's really hard to find the input box by glance. The original webview impl interactive window mitigates this issue by adding padding around the editor input and also change its background

It does stand out but doesn't look consistent with other VS Code components, e.g., scm input, search input, settings editor input, or debug input.

One alternative solution brought by Kai is setting a min-height/line-number for the input box. One example is how the comment widget renders, whose height is always 5 lines of text.

Mock up of how the interactive window might look like with a larger min height:

[IanMatthewHuff]

@rebornix I get that the background color is non-standard, but the design here is still really, really quiet. Expanding the lines to 5 might even make it look less interactive, it just looks like a big white area, not like a text box or input box of any type.

Could we consider bringing back the "next execution count" prompt? For ipython like stuff that's a pretty standard indication to users that there is a typing affordance and that the thing you enter here would be pushed up to the history above.

Like so?

Still doesn't really look like it has textbox affordances to me though.

[joyceerhl]

@daviddossett had a suggestion at this morning's UX sync which IMO solves the vertical height issue while making it obvious that it's an editor you can type into. @IanMatthewHuff what do you think?

It's a similar pattern to the rich text editor present at the bottom of Teams/Slack channels:

@rebornix and I think the language picker is valuable if the currently selected controller supports multiple languages. We might want to hide it for single language kernels.

We were already planning to add UI indicators that the executed cells are readonly, and I think that if we were to adopt the mockup above, we would need that all the more. Otherwise it's not clear what the difference is between the input cell and the rest of the interactive window.

[IanMatthewHuff]

Yeah that design actually helps make it look like a text box. And I like having the execution count indicator in there.

[DonJayamanne]

@rebornix can we have the input prompt on the top of the interactive window. Or should this be filed seprately.
For my kusto notebook extension, i feel users would find having a text input on the top more familiar with Kusto Data explorer & other Data Query tools (I can see this being used by ADS as well, similar to running SQL queries - editor on top & results at the bottom).

[rebornix]

can we have the input prompt on the top of the interactive window

@DonJayamanne please file a separate issue, it's more than moving the input editor to the top, I think we would also need to flip the execution history sequence (last execution shown at the top other than bottom) at least.