Discussion: How should “evaluate” work?

从 evaluate 命令及其 handler 开始，然后检查 Start-EditorServices 如何配置 PSHost 以及独立的或 out-of-process runspace。比较三种提议的输出路径——使用父 host、返回结果或 window/logmessage 事件——并定义一种支持 NamedPipes 且不会产生重复输出的统一行为。

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?