Allow editor commands to be registered in extension code without adding to package.json

[daviwil]

I've got an idea to allow extra extensibility of VS Code using PowerShell via my extension. Here's a proposal that I wrote up with some initial ideas:

PowerShell/PowerShellEditorServices#81

The core requirement for my extensibility model is to be able to add new commands to VS Code after my extension has already loaded, without also having to add them to my package.json. This will allow my users to write new actions, analyzers, and code formatters which they could invoke using VS Code's great keybinding system.

Currently the API lets you register the ID of the command and the function to be called. If we could also get parameters for the display name and category of the command it should be enough to accomplish full dynamic command registration. As a bonus it would nice to have a parameter for registering a default key binding for the command, but it's OK if that comes later.

I realize that there's probably a reason why you'd prefer to have commands be registered in package.json rather than completely in code. My guess is that it allows the commands to be displayed before the extension is fully loaded. The dynamic commands I'd like to have wouldn't need to be displayed until the extension is fully loaded anyway, so this doesn't matter as much to me.

Thanks for considering this!

[egamma]

@jrieken fyi

[daviwil]

Was this meant to be closed? I couldn't find a similar issue in the backlog :)

[egamma]

sorry, wrong button

[daviwil]

I've been talking to a few people about this recently and there seems to be a real interest from users of the PowerShell extension to be able to write new VS Code commands using PowerShell. I'd like to gauge your interest in providing the capability of dynamic command registration so that I can enable this scenario.

I know that on the list of valuable things you could do post-Build, this is probably not very high. However, I think it could open the door to even more ways to extend VS Code using any language without any significant changes to the current extensibility model.

Here's a description of how it would work:

---

The user installs the PowerShell extension for Visual Studio Code. One day, they hear about a new PowerShell module that provides a custom formatting command for PowerShell scripts. They install this module using the PowerShell Gallery.

The next time they start Visual Studio Code, the language service scans their locally installed PowerShell modules for any that contain editor command extensions. The new script formatting extension is found and loaded. This causes a special message to be sent from the language service to the PowerShell extension in VS Code to indicate that an editor command extension was loaded.

The PowerShell extension then uses the VS Code APIs to dynamically register this new command with its ID, display name, and default key binding. If the key binding is already in use, the default key binding is ignored. The user can now see and execute the "PowerShell: My custom formatter" command in VS Code's command palette. They can also bind this command to a key combination of their choosing in keybindings.json.

When the custom command is executed, the PowerShell extension will use VS Code's APIs to gather context about the user's currently open file and the current selection or cursor position. This information is then sent with a request to the PowerShell language service to execute a custom command with the selected ID. The custom command runs its logic in PowerShell and then returns a result which contains edits to be applied to the file.

When the response is returned from the language service, the PowerShell extension will translate the desired edits to the VS Code APIs so that they're applied to the user's file buffer.

---

Aside from code formatting extensions, I'd also be providing general action commands (execute some task) or analysis commands (run some special linter or script checker). The standard VS Code APIs will be used for all extension capabilities.

There are two major benefits to this approach for PowerShell users:

1. They can write new editor commands in a language they're already comfortable with.
2. These same editor commands can be made available in the PowerShell ISE and any other editor where our language service (PowerShell Editor Services) is used.

Would you be willing to accept a pull request from me to enable this after the appropriate design discussion has taken place?

Thanks!

[jrieken]

A workaround is to have a command that opens quick pick with a list of (dynamic) commands. Omnisharp vscode does this for project specific commands and package restore: https://github.com/OmniSharp/omnisharp-vscode/blob/master/src/features/commands.ts#L109

[daviwil]

Yep, this is what I was going to do for now. The main 2 downsides with this approach are the reduced discoverability and inability to bind a hotkey to those commands. I'd prefer it if the extension commands could show up as top-level commands under the "PowerShell" category.

[W4RH4WK]

I had the idea of creating an extensions which allows you to setup commands (and bind them to hotkeys) in a more generic way. This way all the "open-in" / "open-with" / filter selected lines with shell command, ... extensions could be substituted with this generic one.

But since it is not possible to add / remove commands dynamically I did not bother implementing a prototype. I asked (#11045) whether they'd implement such functionality into vscode itself, but they declined.

[geddski]

I wrote an extension that could help with this. It allows you to create custom macros and bind them to hotkeys.

https://marketplace.visualstudio.com/items?itemName=geddski.macros

[bcardarella]

@daviwil this issue is over a year old, has there been any movement on it?

[daviwil]

@bcardarella Not yet, but I'd love to see it get added

[fabiospampinato]

This functionality would be pretty useful to me. I'm making an extension for adding commands like "Open in Chrome/Firefox" to the palette, but configurable, so that if you need to use Yandex or something you can add a command for it, but turns out there's no API for doing this.

Resolving to a QuickPick is a sub-optimal solution.

[OmarTawfik]

This feature would be really useful here as well.
@jrieken @egamma are there blockers that prevent this from happening?
Are you willing to accept a PR to add this functionality to vscode?

[OmarTawfik]

Any thoughts on this? there has been multiple asks from multiple people. Please let us know if it is something that you're willing to take into the platform, or you decided to not support it.

[OmarTawfik]

@jrieken @egamma can you please advise?
This would be useful in case of workspace commands as well, not just editor commands.
Would this be an API change you're willing to accept?

[OmarTawfik]

@jrieken @egamma can you please advise? :)

[ghost]

Yes found that out yesterday it is working now on all editions of windows

[OmarTawfik]

@snewfie is this comment intended here? Which API did you try?

[SeeminglyScience]

@OmarTawfik I believe they meant to respond in SeeminglyScience/EditorServicesCommandSuite#41.

[DavidGoldman]

Friendly ping, this would also be useful for source control to allow users to define their own aliases (e.g. hg amend && hg push)

[jedwards1211]

I'm wanting to contribute to an extension for doing jscodeshift transforms on the current editor, and it would be really nice to be able to map each transform to a separate command. Then users could also assign keyboard shortcuts to each transform command.

As it stands, (and as others have mentioned) I have to use a static command that brings up a quick pick of transforms, so I can't assign a keyboard shortcut to an individual transform.

Static configuration usually leads to an awkward DSL that papers over some of the static limitations but don't fully solve the problem. (extends and env in .babelrc files, intrinsic functions in CloudFormation templates, etc.)

[mrienstra]

@jrieken, 2.7 years later, is this request still "out of scope"?

Would limiting the possibilities to mitigate abuse make it more palatable?

• Limit the number that an extension can add (ideally user overridable).
• Dynamic user facing commands could be required to contain a static prefix or suffix, or match a static regex.
• When (if?) extension permissions exist (see [Feature Request] Extension Permissions, Security Sandboxing & Update Management Proposal #52116), that would be another avenue, letting the user know the extension wants the ability to create dynamic user facing commands.
• Not sure if there is any precedent for this, but it could also require explicit permission from the user for each command or batch of commands added by an extension, e.g. via a confirmation dialog.

[tiejunhu]

This is a major issue blocks vscode to be a hackable editor(like emacs or vim). The editor's user (not plugin/addon author) cannot add a command to the command palette.

[jurgenvinju]

Thanks for making VScode! Having great traction with it for DSL design and implementation.

For extension generators such as Rascal (produces a VScode extension from a "language description") this feature would be very useful. Currently we register one LSP server that multiplexes on file extension to redirect every LSP call to the right language. Every programmable feature that is locked in package.json is therefore out of our reach. The great benefit is that we can roll experiments with new LSP servers without a second level or rebooting. That's worth a lot to our users (typically DSL engineers).

We currently have to give every new DSL-specific command a place as a "lense" instead. It would be better for our users if they can also access DSL-specific commands that are not exposed as lenses but simply in the command palette.

By the way, we have similar issues with other package.json-locked features like language-specific bracket-balancing and comment prefixes/postfixes. A programmable alternative would be great.