* Adopt idle instantiation in editor contributions and use explicit syntax in the ones which need to be eager
* Make sure all editor contributions are eventually instantiated
* Introduce multiple values for `EditorContributionInstantiation` and adopt them
* Allow editor contributions to mark themselves as instantiated on idle
For #164171
Editor contributions are currently created eagerly when editors are instantiated. In many cases however, the contribution is not needed instantly. A contributed widget for instance may only be shown after a user action, while some info that shows in the editor also does not need to be shown instantly as soon as the editor opens
Contributions like those can be lazily created, but actually adopting lazy instantiation for individual contributions is a lot of work
Instead this PR lets editor contributions tell VS Code that the entire contribution does not need to be eagerly created and can be instead on idle
With `EditorContributionInstantiation.Idle`, the contribution will be created:
- Either when the editor is idle
- Or when the contribution is explicitly requested.
Idle contributions cannot participate in saving and restoring of editor view states
This change will make it easier to lazily create editor contributions and also lets us remove existing code that was added to make individual editor contributions lazy
* Mark as optional
* Addressing comments
* IdleValue should throw again if there's ctor error
Instead of having unique versions of `IConstructor` for various argument counts, instead take the expected argument types as a tuple. This cleans up the code a little and lets us pass in as many arg types as we wish
* Add CoreCommandService
For #90110
This change introduce a new service (`ICoreCommandService`) that lets high levels parts of the editor (such as webviews) hook into core commands such as undo and redo that are fired from the editor menus.
## Why is this needed?
To implement undo/redo in custom editors / webviews, we currently register special commands (`editor.action.customEditor.undo` and `editor.action.customEditor.redo`). This is not ideal since it means that users have to update multiple commands if they wish to rebind undo/redo
These custom command also are not invoked when the user goes to the `edit` menu and select `undo` or `redo`. Instead, the edit menu always calls the core `UndoCommand`
We cannot make `UndoCommand` know about custom editors because it lives in `base`
## What this change does?
This change adds a new `ICoreCommandService` that lets higher level parts of the editor override core commands such as undo and redo. We use a similar approach in the `IOpenerService`.
Right now only `undo` and `redo` are overridable. If this approach looks ok, we could also extend it to `copy`, `paste`, `cut`, and `select all`
* Add docs and clean up types
* Rework implementation
Switch from using a command service to having each command state if is overrideable or not.
This hooks up overrides for:
- Undo/redo
- cut/copy/paste
for webviews, custom editors, and notebooks
* Add ProxyCommand so that multiple registered commands can share a single implementation
* Fix compilation & missing file being referenced
* Introduce and adopt MultiCommand for Undo
* Adopt MultiCommand for Redo and SelectAll
* Adopt MultiCommand for Cut, Copy and Paste
Co-authored-by: Alex Dima <alexdima@microsoft.com>
Our code currently uses the `IConstructorSignature` types in a two main ways:
- As argument types in functions that take a service constructor.
- As return types or property types when we expose a service constructor in the API
This first usage is not valid with strict function types. The reason is that the `IConstructorSignature` types takes a rest array of `...services: BrandedService[]` , while the concrete constructors you pass in use actual services. With strict function types, you cannot convert the concrete constructor type to an `IConstructorSignature` because this would drop important type information that the implementation needs. As an example
```ts
class Foo {
constructor(@ILogService service: ILogService) {}
}
registerFoo(Foo);
// The type of `ctor` inlines `IConstructorSignature0`
function registerFoo(ctor: { new(....serivces: BrandedService[]): Foo}) {
// When registerFoo(Foo) is called, the implementation here would need to know that
// ctor needs to be invoked with exactly one `ILogService`. However the type of `IConstructorSignature0`
// does not express this. Strict function types therefore disallows this conversion
}
```
To fix this, I have converted a few places were we were taking `IConstructorSignature` arguments so that they preserve the full type of the constructor. This fixed over half of our 900 strict function type errors. Unfortunatly I can not figure out a more elegant way to express this besides inlining the types
However, even after this change, we still need to figure out how to deal with:
- Places in the code where `IConstructorSignature` is exposed as a return type or object property
- How to deal with all of our descriptor types (such as `SyncActionDescriptor`)
