-
Notifications
You must be signed in to change notification settings - Fork 29.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Introduce share links in more places via a contrib #177311
Conversation
601569f
to
72c7353
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This PR has a layer breaker and I would also argue that it has a conceptual flaw. You might be able to fix the layer breaking (tho not easy) but generally commands should never just rely on the arguments they are being called with. Any extension can call any command at any time and therefore it is best that commands "discover" their arguments themselves.
character: selection.getEndPosition().column | ||
} | ||
}))] | ||
}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not OK because it is a conceptual layer breaker. It introduces extension host types to the renderer, e.g this new argument is wrong for all "internal" context menu actions and wrong for monaco-editor use-cases.
if (this._options?.arg) { | ||
if (this._options?.arg && Array.isArray(this._options.arg)) { | ||
runArgs = [...runArgs, ...this._options.arg]; | ||
} else if (this._options?.arg) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have unfortunately limited capacities for a deeper look but this seems breaking for those cases where use have been using an array as argument, right?
Re: #176316, #175676
I received feedback in #176316 (comment) that introducing multiple share menus, each with their own expected behavior (copying a range, copying a path without a range, and copying neither a path nor a range) is onerous for extensions.
This PR reduces the burden on extensions by passing a more predictable context object to extension-contributed share commands and allowing extensions to register commands in all relevant share submenus with one contrib declaration in package.json. In brief:
It's adopted here for the builtin GitHub extension but also requires adoption in GHPRI and GitHub Repositories.