Add new commands for Find\Install Editor Commands

[gerane]

I want to add some new commands that should make discovering and installing new Editor Commands or modules with them easier. One of the easiest ways we could do this is by writing wrappers around Find-Module and Install-Module. Just change it to only find modules with a particular tag or set of tags.

Editor Commands are a great feature of PSES, but they don't get a lot of attention and are often overlooked. I think if we put some effort into making them easier to use, easier to find, and easier to share, we would start to see more adoption.

Things that I was wanting to discuss and get community feedback on:

What Tag or Tags would be best?

Ex: EditorCommand, EditorCommands, PSES?

What is the best user experience?

In the short term, I could create Editor Command\Commands for Find-EditorCommand and Install-EditorCommand that would tie into the Show Additional Command menu and use the command palette to prompt for user input and prompt users with lists of found modules. Maybe something where it is an Editor Command to Install Editor Commands, and it prompts for a name, displays results in command palette, and then installs the module the user selects in the command palette. However, that really should be just for the short term

Ideally, it is better to have this at the root level. Long term, I think it would be best if this could tie in with an actual GUI and allow users a similar experience to installing extensions. I have not kept up with how far they have come with their webview features, but maybe that could be an option. I also don't know what aspects would be PSES and what would be VSCode Extension.

FInd-Module and listing Editor Commands in the module

It is one thing to list modules with Editor Commands inside, but could we also figure out a way to show what Editor Commands are inside the module and have those get returned by Find-Module? I have not really played around with the metadata enough to know if you can add custom fields and those get passed back. The other issue would be how would you educate people on how to do this.

Is there a standard for importing Editor Commands?

When I first worked with @daviwil on this 2+ years ago, the idea was to conditionally load these by checking for the $psEditor variable. If the module was imported and it was running inside of Code, then it would auto register the Editor Commands. I know @SeeminglyScience uses another method, but I haven't looked into it enough to see what he's doing.

This could be something that could eventually be controlled by a GUI or config, but I am not sure how that will end in the long run. I think the majority of people stick to the defaults and never really go in and tweak the configs of editors, and it could lead to less adoption. Maybe have autoload as the default, and allow for override via config of GUI as an option.

Why now?

I think now is a great time to start pushing and making an effort to get people using Editor Commands. I tried early on, and it was really bad timing. David was pushing hard to get the integrated terminal working, and when he finally did, it pretty much set Editor Commands back a long way. I had to stop pushing people to them due to the Integrated terminal breaking their integration with the command palette. It didn't make sense for David to invest time into them when he was devoting most of his time to fixing bugs and improving performance. I decided to stop trying to push them to people, and to let things settle.

At that point, we were still struggling to get people to switch to code. Now, I think we have great adoption and people are starting to get used to the normal features, so now should be a great time to really improve these and get some traction.

[SeeminglyScience]

What Tag or Tags would be best?
Ex: EditorCommand, EditorCommands, PSES?

I think we should be a little bit more explicit, like EditorServicesCommands. If some other editors have similar concepts in the future (or currently) we wouldn't want to include in the list (because they won't work)

In the short term, I could create Editor Command\Commands for Find-EditorCommand and Install-EditorCommand that would tie into the Show Additional Command menu
...
Ideally, it is better to have this at the root level.

I think VSCode should register them as commands in the extension, and the module should register them as editor commands if the host is not VSCode. Granted, no other editor currently supports editor commands, but it'll be good to have it ready just in case. Plus, I assume any other editor would register editor commands directly to their respective root menu anyway (Atom for example does work this way)

Is there a standard for importing Editor Commands?

Both methods are valid. Register-EditorCommand is great for anonymous editor commands, or just a few here or there. Import-EditorCommand is meant for modules that are built entirely around editor commands.

This could be something that could eventually be controlled by a GUI or config, but I am not sure how that will end in the long run.

Anything we'd do there would have to be editor specific. I'm not opposed to it, but I would definitely still like the existing options to stay. Controlling settings via a line in a profile always seems right to me when PowerShell is involved.

[TylerLeonhardt]

I came here to say exactly what @SeeminglyScience said. +1 for EditorServicesCommands

I want to also add that I'm totally on board with this and I think it's awesome that we can get started on this without making any changes to the extension using existing $psEditor APIs.

That said, I am TOTALLY willing to do work in vscode-powershell or PSES to make this better and get the word out.

[SeeminglyScience]

I want to also add that I'm totally on board with this and I think it's awesome that we can get started on this without making any changes to the extension using existing $psEditor APIs.

My 2 cents: Install/Find-EditorCommandModule (name pending) should be included in PSES in the same module as Register-EditorCommand and the like. They should be registered to the command palette via VSCode purely so they are in the root menu, but in other editors they should be registered as editor commands.

Ultimately I think a separate UI for installing them would be awesome. Something similar to the VSCode extensions bar including search. That would be pretty easy to do using the web view API's (check out gitlen's ui folder for some examples)

I say easy to do, but I when it comes to heavy dom manipulation I only have experience with react.js. I doubt you'd want to bring that in for one UI, so ymmv. The other downside is right now that UI would only show one module afiak. Two when @gerane gets their module published. So until it catches on that may be a little awkward.

[TylerLeonhardt]

My 2 cents: Install/Find-EditorCommandModule (name pending) should be included in PSES in the same module as Register-EditorCommand and the like.

Agreed.

Ultimately I think a separate UI for installing them would be awesome

I wonder if we could take advantage of views:
https://code.visualstudio.com/docs/extensionAPI/extension-points#_contributesviews

You just supply them some json and it renders it for you. As long as we can show/hide it using the command pallet, that will save us from doing actual UI work 😄 It might be worth investigating.

[rkeithhill]

Could but keep this in mind. If we also add a view for the remote PSPR stuff then we start to choke off the explorer visible area. I don't know about you but I've already got views for GitLens and Docker. I really wish VSCode would move these extra views to their own tab.

BTW I experimented with these views several months ago here - https://github.com/rkeithhill/PowerShellDemoIt/blob/master/src/demoExplorer.ts But got pulled off to work on my many other OSS projects. So many projects, so little time. :-)

[TylerLeonhardt]

@rkeithhill yeah that's a big concern. I think the only way we'd go down the view route is if we can easily show/hide it completely.

[SeeminglyScience]

I think the explorer views would be a really neat way to show installed/loaded commands, but may be awkward for finding new ones. I definitely share @rkeithhill's concern as well. The only one I've ever actually used was gitlens, the others are just clutter. ^{_{Why is there no x button :(}}

[TylerLeonhardt]

Well, we could always throw some UI together with Vue.js:

<head>
    <script src="https://cdn.jsdelivr.net/npm/vue/dist/vue.js"></script>
</head>
<body>
    <div id="app">
      {{ message }}
    </div>
    <script>
        var app = new Vue({
          el: '#app',
          data: {
              message: 'yay data binding!'
          }
        })
    </script>
</body>

It has some nice list rendering:
https://vuejs.org/v2/guide/list.html

[rkeithhill]

I think the explorer views would be a really neat way to show installed/loaded commands

If we did this then perhaps we could also show installed commands as well - not just editor commands. Then we'd satisfy another request which is for the ISE's command windows. Kill two birds with one tree view. :-)

[TylerLeonhardt]

ISE's command windows

@rkeithhill YES. I wonder if they're powerful enough to have forms inside similar to that of ISE.

[rkeithhill]

I don't think so but perhaps we have a "show details" toolbar button that opens up an html window - perhaps in a side-by-side mode?? And if we could put a dropdown combobox on the toolbar, that could be search.

[gerane]

One of my ideas, was after something like this goes live, it would be interesting to start going around and adding Editor Commands to open source projects that have good candidates for them, and adding the tag to the manifest.

[TylerLeonhardt]

That'd be really cool @gerane. It spreads awareness while also giving back to the community.