VS Code: use enablement for Cody commands

[valerybugakov]

• The when configuration field is not applicable to commands:
  • To verify disable autocomplete and observe that all autocomplete commands are still visible in the command list.
  • The related JSON schema in VS Code sources confirms this: https://github.com/microsoft/vscode/blob/29aeab1cbb350107a7bd5962b5e7efe745e0a3ec/src/vs/workbench/services/actions/common/menusExtensionPoint.ts#L729-L773. The when field is missing. Only enablement is specified.
  • The VS Code document is misleading: https://code.visualstudio.com/api/extension-guides/command#controlling-when-a-command-shows-up-in-the-command-palette
• This PR changes all when fields to enablement to hide Cody commands under certain conditions.
  • Design input required: we use "cody.activated && editorTextFocus" in multiple places. It does nothing in the current version of the extension, but with the enablement field, it hides the respective command from the quick pick menu (shift+command+P) even when it's opened from the editor. Technically, the editor is not focused anymore; the quick menu is. So this configuration can be treated as: "the command will be hidden from the commands list, but will be available via keybindings if editorTextFocus".
  • Related discussion: editorFocus is still true when launching the command palette microsoft/vscode#124755.
• Resulted from the question here add experimental vscode command to get completions from multiple models #4048 (comment)
• Created a follow-up to prevent such issues in the future VS Code: validate the extension config using JSON schema #4156

Test plan

1. Start the extension locally.
2. Disable autocomplete.
3. Observe that the manual trigger command IS NOT present in the commands list (shift+cmd+P).
4. Enable autocomplete.
5. Observe that the manual trigger command IS present in the commands list (shift+cmd+P).

Can be done for all the commands based on the conditions specified in the enablement value.

[valerybugakov]

Cc @toolmantim @umpox, check out the "design input required" point in the PR description.
It affects most of the commands.

[philipp-spiess]

@valerybugakov These current when conditions are unused and probably just copy-paste errors. This particular command is also hidden in the commandPallete setting like so:

    "menus": {
      "commandPalette": [
        {
          "command": "cody.command.edit-code",
          "when": "cody.activated && editorIsOpen"
        },

So I believe this works fine right now.

[valerybugakov]

@philipp-spiess all autocomplete commands are still enabled when autocomplete is disabled. I think we should fix that.

[philipp-spiess]

I don't think this is the correct approach. most of the commands have entries in commandPalette already and are already gated out (these are in prod, after all) so we shouldn't change this.

For those that aren't I'd say we err on the side of removing the check to avoid breaking anything. See this: #4157

[valerybugakov]

@philipp-spiess, do we want to turn off some commands entirely in some cases? e.g., multiModelCompletions when the setting is empty or autocomplete manual trigger when autocomplete is disabled?

[philipp-spiess]

@valerybugakov What's the functional difference between turning-off via enabled and turning off via entries in commandsPallete and shortcuts with a when? 🤔

[valerybugakov]

@philipp-spiess, probably one source of truth? If we know that the autocomplete manual trigger command should be disabled for both the command palette and the keybindings when autocomplete is disabled, should we do it in one place?

In the current vesrion, it does not work as expected, probably because we assumed when in commands works.

[valerybugakov]

I think we should remove redundant when statements. For example, it's not needed for the edit command. But for a bunch of other commands, it's the right way to control on/off state. WDYT?

[philipp-spiess]

@valerybugakov If it simplifies things than yeah, but I worry that we mess something up and break something in prod for this. Maybe we can check if commands have entries in both commandPalette and the keyboard shortcuts, we can move it to enablement instead? But that means we also can't trigger the command via code so we'd also need to grep for it inside the code I think, to ensure we don't have regressions (or maybe it's currently working unexpectedly too). Do you think it's worth it to spent this time now?

[valerybugakov]

@philipp-spiess, from sources

Does not prevent executing the command by other means, like the executeCommand-api.')

So it should not break anything if we remove redundant when statements and convert the rest to enablement. I think this simplifies the setup and we won't need to invest additional time into it.