Repository navigation
Make sure markdown links execute an ext-host vscode.open command always #154993
Description
Activity
I believe the root cause is that this ends invoking the renderer version of
vscode.open:vscode/src/vs/workbench/browser/parts/editor/editorCommands.ts
Lines 486 to 495 in 2c036d1
CommandsRegistry.registerCommand({ id: 'vscode.open', handler: (accessor, arg) => { accessor.get(ICommandService).executeCommand(API_OPEN_EDITOR_COMMAND_ID, arg); }, description: { description: 'Opens the provided resource in the editor.', args: [{ name: 'Uri' }] } }); Instead of the one on the extension host that supports all the additional arguments
I also tried using
_workbench.opendirectly. That doesn't work well since we don't go through the ext host type conversions. This means that theselectionargument in the first example doesn't work since it has the wrong shapeThis needs special handling, like done for tree views etc, but that also means extensions cannot (and should not) be able to control the opening details but that the user-gesture (ctrl+click vs normal click) determines the "to the side" behaviour
Took me a while to understand. First of all,
vscode.openis clearly supporting an argument to open to the side:vscode/src/vs/workbench/api/common/extHostApiCommands.ts
Lines 381 to 392 in 4404dc6
new ApiCommand( 'vscode.open', '_workbench.open', 'Opens the provided resource in the editor. Can be a text or binary file, or an http(s) URL. If you need more control over the options for opening a text file, use vscode.window.showTextDocument instead.', [ new ApiCommandArgument<URI | string>('uriOrString', 'Uri-instance or string (only http/https)', v => URI.isUri(v) || (typeof v === 'string' && matchesSomeScheme(v, Schemas.http, Schemas.https)), v => v), new ApiCommandArgument<vscode.ViewColumn | typeConverters.TextEditorOpenOptions | undefined, [vscode.ViewColumn?, ITextEditorOptions?] | undefined>('columnOrOptions', 'Either the column in which to open or editor options, see vscode.TextDocumentShowOptions', v => v === undefined || typeof v === 'number' || typeof v === 'object', v => !v ? v : typeof v === 'number' ? [typeConverters.ViewColumn.from(v), undefined] : [typeConverters.ViewColumn.from(v.viewColumn), typeConverters.TextEditorOpenOptions.from(v)] ).optional(), ApiCommandArgument.String.with('label', '').optional() ], ApiCommandResult.Void ), This particular issue seems to be around command links in a document (which I am not aware of how they work). If I understand correctly, these links execute on the renderer and not on the extension host and as such, the additional arguments are not supported:
vscode/src/vs/workbench/browser/parts/editor/editorCommands.ts
Lines 484 to 495 in 4404dc6
// partial, renderer-side API command to open editor // complements https://github.com/microsoft/vscode/blob/2b164efb0e6a5de3826bff62683eaeafe032284f/src/vs/workbench/api/common/extHostApiCommands.ts#L373 CommandsRegistry.registerCommand({ id: 'vscode.open', handler: (accessor, arg) => { accessor.get(ICommandService).executeCommand(API_OPEN_EDITOR_COMMAND_ID, arg); }, description: { description: 'Opens the provided resource in the editor.', args: [{ name: 'Uri' }] } }); Why can the renderer side not simply allow for the same options?
- addedinfo-neededIssue requires more information from posterIssue requires more information from posterworkbench-editorsManaging of editor widgets in workbench windowManaging of editor widgets in workbench windowand removedinfo-neededIssue requires more information from posterIssue requires more information from poster
on Jul 13, 2022 Why can the renderer side not simply allow for the same options?
Because those are API objects and no one transforms them into internal objects
but that the user-gesture (ctrl+click vs normal click) determines the "to the side" behaviour
It seems to me that Matt wants to always open to the side, irrespective to the user-gesture?
If so, I believe this is a feature request for document links to:
- either execute from the ext host side
- or to add simple arguments to the renderer side for this particular scenario that does not drag in API types
Let's maybe sync the three of us in August.
1 remaining item
- addedfeature-requestRequest for new features or functionalityRequest for new features or functionality
on Aug 19, 2022 - addedmarkdown-extThe Markdown extension: language features and previewThe Markdown extension: language features and previewand removedfeature-requestRequest for new features or functionalityRequest for new features or functionalityworkbench-editorsManaging of editor widgets in workbench windowManaging of editor widgets in workbench window
on Sep 7, 2022 - changed the title
[-]`vscode.open` on document link doesn't accept additional arguments[/-][+]Make sure markdown links execute an ext-host `vscode.open` command always[/+]on Sep 7, 2022 As discussed, the suggested fix is to call a
vscode.openclone that ensures ext-host side execution and argument conversion.Fixed by 077f586
Reacted by Benjamin Pasero- added*dev-questionVS Code Extension Development QuestionVS Code Extension Development Question
on Sep 8, 2022 - locked and limited conversation to collaborators
on Oct 23, 2022
I'm trying to use
vscode.openwithDocumentLinkProvider. At present, only the first argument ofvscode.open(the resource) seems to be respected. The other arguments are ignored.Here's an example extension that demonstrates this issue:
To repo:
abc.mdin the root of your workspace. Add a few lines of content to itExpected
This should open
abc.mdbesides the current editorActual
abc.mdis opened in the same view column