From discussion with @greazer @rchiodo @claudiaregio @rebornix

Existing feature requests:

• Support a notebook "scratch pad" and/or integrate interactive window experience for notebooks #4573
  • "I add some cells to try something out and I don't want to lose them, but I don't want them in my 'main' notebook."
• Support a scratchpad for a jupyter notebook #6484
  • "...interactive command line that is connected to a jupyter notebook..."
• Add option for creating interactive console connected to the notebook kernel #6033
  • "...create interactive Python consoles connected to specific notebook kernels. The main usecase is to be able to work interactively based on the state of a notebook without having to tinker with the notebook itself."
  • "...have an ability to launch an IPython shell (within VS Code) which is binded to the kernel of a specific notebook (so all objects defined in the notebook are accessible there etc.)..."

Proposed experience:

• Command contributed to notebook/cell/title to open interactive window connected to same kernel
• Command contributed to interactive/cell/title to paste code back into notebook
• Kernel picker to be hidden
• Sys info cell to indicate the notebook association
• Context keys to hide interactive window specific functionality
• Title should say 'Scratchpad'
• Should the interactive window immediately receive focus when created?

Bare-bones prototype:

Open questions

• Should users be able to start multiple interactive consoles? Original prototype has scratchpad singleton
• Should the scratchpad contain just the one cell (fully matching https://jupyter-contrib-nbextensions.readthedocs.io/en/latest/nbextensions/scratchpad/README.html behavior) or be a full interactive window?
• Introduce keybinding or similar to copy code (otherwise user has to move mouse literally the entire span of the screen)

Engineering notes:

• Summary: Jupyter extension needs to refactor our VSCodeNotebookController wrapper, IKernel, and the cell execution codepath to allow
  • an IKernel that is currently mapped to a jupyter-notebook controller which has been selected for a given jupyter-notebook NotebookDocument
  • to be reused for an interactive controller that is selected for a given interactive NotebookDocument
• Current state/background
  • Currently vscode.NotebookControllers are per-notebookType, so to get our kernels to show up for interactive windows, each of our kernels is registered twice with VS Code--once for the jupyter-notebook notebookType and once for the interactive notebookType
  • Our code currently assumes a 1-1 relationship between a VS Code NotebookController and our internal IKernel objects, i.e. controller is passed into IKernel constructor and then passed all the way down through the constructors of KernelExecution, CellExecutionQueue, CellExecution etc. in order to create the notebook cell execution task
  • Controllers can only create execution tasks for the NotebookDocument that they are currently associated with in VS Code
  • Our code currently also starts a new kernel for each new NotebookDocument in kernelProvider.getOrCreate
  • Interactive window needs to be passed a controller ID at creation to pick up the right controller (alternative is notebook.selectKernel or similar after the window is created, but we've discussed this and decided not to do it). NotebookDocument is returned from interactive.open, so given the jupyter-notebook controller currently selected for a Jupyter notebook, we need to find the matching interactive controller that we told VS Code about, and make sure that the underlying kernel is reused
  • Note, this also means that if we want arbitrary notebooks to be able to start an interactive session, then all those extensions must ensure that they return the same instance for jupyter-notebook and interactive notebookTypes (not guaranteed to work OOB)