Share "Reopen with" command and Editor Associations with notebooks, settings and keybindings UIs

[Tyriar]

Notebooks, settings UI and the keybindings UI are very similar to custom editors. We should make the command more generic so the method to view the backing file in the text editor is shared and behaves the same across each of these editors.

[rebornix]

Internally we are all using EditorService.overrideOpenEditor(handler: IOpenEditorOverrideHandler): IDisposable; so it makes better sense that we implement the Reopen ... inside the service.

[TylerLeonhardt]

I'm thinking about prototyping a "PowerShell Notebooks" experience where the backing file is a regular .ps1.

I want to be able to toggle between rendering the .ps1 in the regular text editor & rendering the .ps1 as a Notebook.

Having a mechanism to do this would be fantastic.

[rebornix]

Above is the prototype for shared "Reopen with..." command. Previously every "custom" editor registers a simple editor override handler

export interface IOpenEditorOverrideHandler {
  (editor: IEditorInput, options: IEditorOptions | ITextEditorOptions | undefined, group: IEditorGroup): IOpenEditorOverride | undefined;
}
interface IEditorService
  overrideOpenEditor(handler: IOpenEditorOverrideHandler): IDisposable;
}

Now the IOpenEditorOverrideHandler is enriched as

export interface IOpenEditorOverrideHandler {
  open: (editor: IEditorInput, options: IEditorOptions | ITextEditorOptions | undefined, group: IEditorGroup) => IOpenEditorOverride | undefined;
  canOpen: (editor: IEditorInput, options: IEditorOptions | undefined, group: IEditorGroup | undefined) => {  id?: string; label: string; description?: string; detail?: string; }[];
}

The shared "File: Reopen with..." action will show all custom editors (which can be multiple CustomEditors, multiple Notebook Editors, two types of Settings Editors and one Search Editor) which can handle the resource for users to choose from.

We also need to think about how to configure the default editor for a resource. @mjbvz added settings for CustomEditor but considering that the same file extension can be supported by different contributors.

@mjbvz @sandy081 @roblourens @JacksonKearl thoughts?

[rebornix]

As the first step, I can add this action and adopt it in Notebook and then later on you can adopt it gradually in your "custom" editor.

[rebornix]

The QuickPick now aligns with Custom Editor per feedback from today's sit-down

Pushed my first attempt to master dc1746e . To adopt the change in your editorOverride:

1. Implement IOpenEditorOverrideHandler.getEditorOverrides

 this.editorService.overrideOpenEditor({
  getEditorOverrides: (editor: IEditorInput, options: IEditorOptions | undefined, group: IEditorGroup | undefined) => {
  ...
  return [
    {
      label,
      id,
      active,
      detail
    }
  ];
  }
}

Note that the editorInput passed in can be any kind of IEditorInput, while previously it's FileEditorInput most of the time.

The return type is IOpenEditorOverrideEntry[]. If you are returning multiple entries, make sure the id property is unique thus you know which one users pick

Handle Reopening

The editor input reopen override handler now has one more optional parameter id. If it's undefined, it means users attempt to open the file through File Explorer, etc. If it's not empty, users pick the IOpenEditorOverrideEntry explicitly.

[mjbvz]

Thanks @rebornix. The approach looks good like a good start. I'll look into adopting it for custom editors.

I think it's also worth considering adopting more concepts from custom editors for notebooks and settings. For example, the workbench.editorAssociations setting lets users configure which custom editor is used for a given resource. This is very similar to what the "workbench.settings.editor" setting also does.

[rebornix]

@mjbvz workbench.editorAssociations sounds a good config for mapping between file associations with "custom" editors. We use viewType as well for the notebook, in order to align with Custom Editor. So I think we can move it out to workbench/files from custom editor?

Settings and Keybinding can also register themselves with viewType like settings.ui, settings.json, keybinding.ui, keybindings.json and then users can use workbench.editorAssociations and deprecate settings like workbench.settings.useSplitJSON.

[mjbvz]

@rebornix I hooked custom editors up to use the shared api.

The only missing feature from the shared command compared the custom editor one is that custom editors show a gear icon:

Clicking this gear sets workbench.editorAssociations for the file. I feel this improves the discoverability of workbench.editorAssociations

I see two options:

• Add the gear as a shared feature. Clicking on it would set workbench.editorAssociations for both notebooks and custom editors

• Let custom editors contribute a button to the reopen with quick pick.

@rebornix Would notebooks also benefit from making workbench.editorAssociations more easily configurable?

[rebornix]

Add the gear as a shared feature. Clicking on it would set workbench.editorAssociations for both notebooks and custom editors

@mjbvz yes, notebook will have similar problems and having the gear as a shared feature makes best sense. Will you do the migration? I can do that as well.

[rebornix]

@mjbvz adopted the gear icon in the quick pick, which will set editor association. It's safe to deprecate the "View: Reopen with..." command from Custom Editor now.

[mjbvz]

@rebornix Thanks! I'll move over any other custom editor functionality that makes sense to share

[TylerLeonhardt]

@rebornix is this an editor command I can take advantage of in an extension?

[rebornix]

This one is an internal one for now but I've heard that @mjbvz is making a generic public command to open a resource with a specific "custom editor"

[mjbvz]

70a890e make the vscode.openWith command support other editor types besides custom editors

[sandy081]

Can somebody please explain to me what needs to be done here for Keyboard Shortcuts editor and any code references?

[rebornix]

@sandy081 Keybindings contribution needs to register itself as an IOpenEditorOverrideHandler

vscode/src/vs/workbench/services/editor/common/editorService.ts

Line 246 in 1ed5e6c

overrideOpenEditor(handler: IOpenEditorOverrideHandler): IDisposable;

and as a handler, it is responsible for

1. getEditorOverrides, provides override candidates for a specific resource. For example, there are three different view types for keybindings.json: UI, Split JSON editor, simple JSON editor. The return result will be used in Editor: Reopen With.
2. open(editor: IEditorInput, options: IEditorOptions | ITextEditorOptions | undefined, group: IEditorGroup, context: OpenEditorContext, handles the editor opening override This one is a bit tricky and we are looking into improving it, but now it works as

• If users try to open keybindings.json directly, editor is a FileEditorInput. If options?.override is not set, we should open Keybindings Editor based on user settings (for example, by default it opens the UI editor)
• if options?.override is set, open the right editor based on options?.override (it's the id of the override candidate)

[vscodenpa]

We closed this issue because we don't plan to address it in the foreseeable future. If you disagree and feel that this issue is crucial: we are happy to listen and to reconsider.

If you wonder what we are up to, please see our roadmap and issue reporting guidelines.

Thanks for your understanding, and happy coding!