PowerShellEditorServices
PowerShellEditorServices copied to clipboard
PowerShell
Using DAP OutputEvent over stderr for results
Prerequisites
- [x] I have written a descriptive issue title.
- [x] I have searched all issues to ensure it has not already been requested.
Summary
Currently it seems output streams of the debugee are routed to stderr of the editor services. Is there a reason DAP OutputEvent are not being used for this? Context: https://github.com/mfussenegger/nvim-dap/discussions/1419#discussioncomment-11893631 The DAP client for nvim recently started routing stderr of debug server to logfiles rather than showing it to users. This change on client side now prevents me from seeing the outputs streams of my debugee in neovim. Apparently most debug servers use OutputEvent to communicate output streams, so clients will be more likely to have support for this!
Proposed Design
Use OutputEvent to communicate the output streams rather than stderr.
@Willem-J-an thanks for your submission! I imagine this is probably some legacy behavior as PSES predates DAP. I agree this is something we should at least support with an option, marking "Up for Grabs" and will shepherd PRs if someone gets to it before me.
After doing some initial investigation, I imagine it has something to do with this in the DAP spec:
Debug adapters are free to launch the debuggee however they choose. Typically the debuggee is launched as a child process and its output channels are connected to a client’s debug console via [output](https://microsoft.github.io/debug-adapter-protocol/specification.html#Events_Output) events. However, this has certain limitations, such as not being able to write to the terminal device directly and not being able to accept standard input. For those cases, launching the debuggee in a terminal is preferable.
Since PowerShell typically operates as a host, and there's some janky stuff we need to do when hitting a debug to be able to get PSCallStack on remote powershell sessions, it would be my guess this is the reason. That being said, I'm sure we can figure something out where, as long as the session is local, to have an alternate output option,