Share and Copy As consolidation

[kieferrm]

Version: 1.71.0-insider
Commit: bcb31b9
Date: 2022-08-09T17:04:54.174Z
Electron: 19.0.11
Chromium: 102.0.5005.167
Node.js: 16.14.2
V8: 10.2.154.15-electron.0
OS: Darwin arm64 21.6.0
Sandboxed: Yes

As well as 1.70 stable.

The current state:

1. Share is only available in the File Menu.

2. Copying file URLs for GH is available in the edit menu under Copy As...

3. The explorer context menu inlines the Copy file URLS for GH actions, but doesn't have Share.

4. The editor context menu has "Share" and "Copy As" submenus.

I think there is need for consolidation here:

1. The explorer and the editor context menu should be aligned on "Share" and "Copy As"
2. In both context menus "Share" share should take the place of "Copy As". I personally don't see any good reason to have both and "Share" is closer to the goal users pursue.
3. The consolidated "Share" should be in the File or Edit menu (but not in both).

[chrisdias]

In a nutshell, the Share menu should look like this?

Share >
  Copy vscode.dev link
  Copy GitHub Permalink
  Copy GitHub Permalink as Markdown
  Copy GitHub Head Link

Should we have Copy GitHub Head Link as Markdown as well? How often are these used?

I think it would be great to also include the Publish to GitHub command here as well if not backed by a GitHub repo already.

[alexr00]

Maybe we should just rename the "Copy As" menu to "Share" if we don't want to have both?

[kieferrm]

Maybe we should just rename the "Copy As" menu to "Share" if we don't want to have both?

💯% yes. That's the proposal.

[kieferrm]

And when I use GH Remote Repositories on desktop I don't have "Share" at all, and I don't have any way to easily get the corresponding vscode.dev url for the file I look at. @joyceerhl

[alexr00]

We currently rely on the built in git extension to understand whether there are repositories. We have a couple options if we want to support share where we don't have information from the git extension:

• Have extension API that abstracts away where the repositories come from. This is how GitHub Pull Requests and Issues works. If we go this route, maybe we remove all that abstraction away from GHPRI and put it the built in GitHub extension. Then GHPRI can take a dependency on the GitHub extension.
• Or, Remote Hub can contribute the Copy vscode.dev Link command.

The first option sounds like a good longer term goal.

[joyceerhl]

RemoteHub can contribute the Copy vscode.dev Link command in the short term to align the web and desktop experiences. @alexr00 I will submit PRs for that (requires proposed API access).

[alexr00]

After some further discussion, we won't do the GHPRI/GitHub/git refactor at this time as the payoff doesn't seem worth it. That's now tracked here: #159763

I will still work on the consolidation of the menus in September.

[alexr00]

Not all the extensions that currently contribute to the "Copy As" menu aren't really contributing "Share" commands. Here's what the "Copy As" menu looks like with Gitlens installed:

"Copy SHA" and "Copy Message" aren't related to sharing. Arguably, the "Copy GitHub Permalink as Markdown" command is also not "Share". I think we still need the "Copy As" menu.

I'll move all the "Copy GitHub" commands into the "Share" menu though.

[alexr00]

Share menu with these changes:

Which, with the extensions I have installed, leaves me with this in the Copy As menu:

[alexr00]

Summarizing some team discussion:

• "Copy As" makes more sense since all the commands are copy commands.
• "Share" sounds like something that should have more than just "Copy" commands.
• Most of the team feels that "Share" is not needed if we have "Copy As".
• On the other hand, some folks didn't think to look for the permalink commands under "Copy As" because they sound more like "Share" commands.

Our goal with introducing the "Share" entry point was to make it easy for users to find the "Copy vscode.dev Link" command. But I still don't think that we should simply rename the whole "Copy As" menu to "Share". I'm inclined to keep the changes in #157722 (comment), but only if we're confident that we won't change them again next iteration.