Editor feature that spans multiple cells

[eteq]

Right now if I do an alt-click (or ctrl-d) in the notebook extension it behaves just like the regular editor within a single cell. However, my workflow often involves using multi-select throughout a notebook because I have the same variable/whatever repeated in multiple cells near each other, but not in the same cell. It would be extremely useful if there was a way to make multi-cursor selections span multiple cells.

In fact, my work flow right now is to open a notebook in text only mode and use multi-select there with the jupyterlab interface open in a browser window. With this feature implemented I could dispense with the headaches of saving and reloading there and have it all in one vscode interface.

[IanMatthewHuff]

Thanks for the suggestion. That does sound like a handy feature. Right now each cell is (as you noticed) treated as a separate editor.

[greazer]

Supporting this across cells is a core Code issue to solve.

[vscodenpa]

This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

[cipri-tom]

@Yoyokrazy do you think this would be included in the backlog at some point ? I think it's important but super difficult to search for it ; took me multiple tries and I almost opened a new one. So it's very tough for other people to find and upvote.

Without this feature, there is no useful "Refactor" feature. When I try Refactor, it says there are no refactorings available. Whereas I'd like to at least be able to change the name of a function / variable.

Edit: it seems interesting that the Python extension can correctly identify tokens across cells, since it underlines in yellow occurences of a function after I rename it in a different cell.

Cheers !

[Yoyokrazy]

Updates from an initial exploration into this:

cc/ @rebornix Basic work has been done to explore this concept of multiple selections across multiple cells. Initially there was thought surrounding alt-click multi-cursor implementation, however a number of unknowns will make that an increasingly complex issue to solve. The standard monaco editor performs hit tests and detection to properly place secondary cursors, and the logic to implement that in a notebook editor with a number of editors in a list view would be overly complex to begin with.

The initial work has gone with the approach of creating a cmd+d multiselect action that overrides the standard code editor action. This action will only be enabled with a tight when clause, and allow the user to find and select multiple occurrences throughout multiple cells of the notebook.

---

More thoughts, but bulleted:

• Finding matches
  • initially I was going to use the NotebookFind model, however a lot of the implementation details for this are unnecessary and bring complexity to this that just isn't needed
  • textBuffer is a lot lighter weight, and is very easily accessed thanks to the NotebookTextModel holding the buffer attached to each of its cellTextModels
  • can easily iterate over cells using the Notebook text model, letting you find matches in editors outside of the viewport, and using the NotebookEditor it's not difficult to get the cellViewModel and then focus the cell and selection within.
• Tracking Matches
  • Matches are cells containing occurrences of the word that cmd+d was initially triggered upon, and are all tracked on the NotebookMultiCursorController (one per notebook)
  • They take the following shape

    interface TrackedMatch {
    cellViewModel: ICellViewModel;
    selections: Selection[];
    config: IEditorConfiguration;
    decorationIds: string[];
    }

• • we store the config to address polyglot notebooks, as later in the editing state we will need to spin up cursorsControllers per tracked cell, and they need an editorConfig. Since this can be different across languages, caching this per tracked cell is convenient.
  • cellViewModel is stored to allow easy selection application, focusing, and also decoration management.
  • if there are multiple occurrences in a single cell, that's just one tracked match, but with updated selections
• Decorations
  • Due to editor widgets being blurred as they aren't focused, cursors at the end of selections are lost and selection highlighting is dimmed -- making it difficult to tell when you are really in this notebook multi selection mode
  • solution to this was to highlight matches with a fairly obvious decoration (bright fuchsia at the moment...) as you traverse cells and find matches
  • once editing begins, the decoration shortens to just a mock cursor at the editing point, to signify still being in the editing mode of the multi selection controller
• Anchor Cell
  • This is a concept that allows editing to happen, as we need to be catching things like typing events in order to properly have them take effect in other editors.
  • Each time there is a match tracked in a new cell, this active cell will become the new anchor. With the new anchor cell, there will be updated cursorControllers (since we should not create one for the active cell, it inherently already has one), and listeners are disposed of and recreated for this anchor
• Editing
  • This is the crux of the issue, namely stemming from editors and textmodels being disposed off the viewport of the cell list view
  • Currently supported is only basic typing (not including backspace yet), as this can be accomplished by just creating a new CursorsController per tracked cell, and feeding it the selections from the TrackedMatch that it's associated with.
  • We also create text model refs before creating cursorControllers, as we need to resolve these for cells that are off the viewport
• Event Relays
  • This is currently the thought for how to handle non-core editor commands. This would include things like moving entire lines with something like alt+arrow, and commenting lines out with ctrl+/
  • There's an issue here, as these editor commands take the selection from the cell that would do the relaying (ie the anchor cell) and apply the command based on that. However, since the goal would be to support cells not on the viewport, that would create issues as those editors are disposed
  • currently @rebornix has done some work with preserving editors outside of the viewport, however this is currently scoped to just preserve the focused/active editor (meaning you can type in an offscreen cell), potentially could be used to just preserve all editors? Then this could potentially avoid relaying events to other cells, as we could just get the editor itself
  • perf implications would have to be thought about, but could take an early next step and maybe just impose a pseudo arbitrary limitation of x amount of preserved cells

---

Todo tasks:

• [x] decoration polish

  • a better system than highlighting matches in bright pink as you traverse cells
  • ideally with css we can mock a fake cursor in non-focused cells, can likely be done with some simple animation and the current size/shape

• [x] Support for basic core commands

  • this includes cut/paste/deleteLeft(backspace)/compositions

• [ ] Undo/Redo stack

  • intelligently pushing undo/redo elements to allow undo/redo for the same chunks across multiple cells on/off the viewport

• [x] Support for editor commands

  • will require relaying the CodeEditorWidget event for onTrigger and then passing along the associated id and payload