The WorkspaceTestCollectionService duplicated collection logic
unnecessarily. Centralize to the TestService's collection.
This also moves the state updates for discovering tests, and a new
update for adding roots, into the diff, which lets us synchronize those
changes with the changes to test collections.
There's a super crazy bug with the "run all" action that I have
not dove into yet.
Fixes#114543
External and internal callers to openExternal may not expect (or want) their urls to be handled by a contributed opener. This change makes it so you have to explicitly enable using contributed openers when calling openExternal.
It also enables using contributed openers for a few places in our codebase
* Add ts server for inline hints
* Add some feature related configure
* Add more config
* Rename all options
* Support range
* Add new contribution point to allow specific context menu of inline hints.
* Fix filename
* Pass range into command
* Support trigger position and prefix/postfix
* Support hover message and contextValue
* Add event listener
* Avoid demo command
* Avoid ts changes
For #109277
- Add `option` opener priority. This means the oper will only be shown if requested but will not replace the default opener
- Persist registered openers for IntelliSense suggestions
If the user has configured a specific external uri opener, we should always try to use that without first calling `canOpen` to filter down the list of openers.
This change also adds `ExternalUriOpenerEnablement` which allows an opener to mark itself as the preferred opener for a given uri. If only a single preferred opener is returned, it will be used automatically for that uri (although user configuration can override this)
- Add error notification if opener throws an exception
- Add public facing id to openers. This is used in settings
- Add intellisense for the opener id setting
This workbench service handles opening external uris. Unlike the core OpenerService, it also has logic for configuring a default opener and prompting if multiple openers are availble for a given uri
This changes makes a few changes to the openers:
- Move the opener prompting from the extension host into the main thread
- Make the external opener process two phases: get openers and then open. This would let us skip the trusted domain validation for extension handled links if we want to in the future
- Add lifecycle to commands used by the uri opener
For #109277
This change moves the extension uri opener contribution point to instead use the internal `IExternalOpener` api instead of the more generic `IOpener` api. This is required since external uri openers should see the resolved uri that has gone through port forwarding, not the raw uri that the user clicked on
