Hook up PSES events to PSEventManager

[SeeminglyScience]

Right now the only way to register event/request handlers is to override them via IMessageHandlers from the component registry. This has a few issues

1. As far as I can tell this only allows you to override handlers, not add to them. Doing this as part of an extension module would break existing functionality.

2. These delegates are invoked from a thread that doesn't have a default runspace. This means if the delegate is a converted script block it will fail (and crash PSES)

I propose we add the following:

1. Function or cmdlet Register-EditorEvent. This should work like Register-EngineEvent. It would take a SourceIdentifier as the event name and script block to register as a PSEventSubscriber. Ideally this would also include argument completion for event names.

2. A class that holds constants with event names (see PSEngineEvent)

3. Additional logic to existing handlers and other events to check for relevant event subscribers and if found generate the event.

4. If the event/handler typically returns a value, a property would need to be added to the EventArgs to handle output (PowerShell eventing doesn't handle delegate output)

This would solve a few issues

1. Extension modules could register additional handlers the same way in PowerShell and compiled languages

2. Eventing should take care of all the runspace management and queuing of commands that would normally make this a huge pain. This would also allow the events to be ran in between sequence points of an in progress command.

3. Allow multiple handlers for a single request/event

[rkeithhill]

This sounds cool. Do you have specific user scenarios in mind for this? Is this to hook events like OnSave(), OnDebugStarting/Ending?

[SeeminglyScience]

Some time ago I took a crack at implementing a component base so you could implement code lense/symbol providers with PowerShell. It worked pretty well, but it needed a dedicated runspace and was overly complicated. Anyway, that's what sparked it, but (mostly) anything we typically run in the background is a good candidate.

Some other ideas off the top of my head

1. Custom code action providers

2. All the text document events - didSave/didClose/didChange/didOpen

3. If VSCode (or any other editors) expose any generic events like on click

4. Debugger events like you mentioned. It would be really cool to set up an event subscriber on DebuggerStop with logic to do something like continue if stopped in a pester block. That's basically justMyCode which should probably be it's own issue, but it'd be cool to give really fine control over the debugger.

[TylerLeonhardt]

This sounds awesome! A side effect of this that you touched on is that we give the users more of an ability to use PowerShell to extend PSES. It's only fitting. Some one shouldn't need to know C# in order to do this.

[SeeminglyScience]

@tylerl0706 Yup! That was the original motivation. I tried to implement a symbol provider for classes in PowerShell and it instantly crashed every time I requested symbols :)