Discussion: How should “evaluate” work?

Start with the evaluate command and its handler, then inspect how Start-EditorServices configures the PSHost and separate or out-of-process runspaces. Compare the three proposed output paths—parent host use, returned results, or window/logmessage events—and define one agreed behavior that supports NamedPipes without duplicate output.

Tagging @rjmholt and @andschwa

I discovered that the evaluate command has result hardcoded to ""

I don't necessarily think this is a bug since the output is supposed to be written to the host. However, in scenarios where we are strictly connected over NamedPipes, we have no way to gather the output.

My calling application already has a custom PSHost that sends output to the terminal over SignalR, so I tweaked the PSES code to use the host from my runspace instead of the one you guys created, and everything worked as expected. However, this means I need 2 websockets connections, one for JSONRPC and another for SignalR.

I have 3 ideas for fixing this and wanted you guys' take on it:

1. Add -UseParentPSHost parameter to Start-EditorServices
   This would be the easiest to implement. We already have the parent process's Host in the configuration object. Yes it will require my application to maintain a separate socket, but I'm doing that anyway.

I'd just need to ensure this host is also used when creating separate or out of process runspaces.

2. "Fix" the evaluate handler to return the result of the command so I can display that on my terminal. This gets hairy because then you have to ask whether you want the result to be the string output you'd see on the console or some sort of object representation that can easily be parsed by the calling application. For the sake of argument let's say the result should be terminal output string with colors encoded and all that. This can be accomplished by collecting all the output in the PSHost into a string and sending it along. However that means you get no output at all until execution completes which is undesirable for long running operations.

3. Make you guys' PSHost send window/logmessage events. I think this is the best way to do it, however I'd be concerned it could lead to duplicate output in the VS Code console as you guys are likely showing both stdout AND the window/logmessage event data.

I'd love to hear you guys' thoughts. Is there an easier way to do what I'm trying to do that I have perhaps overlooked?