Proposal: add a request for standard input

[eliphatfs]

There are output events that allow the DAP to send debuggee stdout/stderr to the host. So why not the other direction.

[weinand]

@eliphatfs ... because output is easy:
whenever the DA receives output from the debuggee, it just forwards it via the DAP output event.

But how exactly should input work?
Could you please make a proposal?

[eliphatfs]

Output is passed through an event, while I think input can be made a request. DA just forwards the request to stdin of the debuggee -- in what cases will this be harder than receiving output from debuggee?

[weinand]

@eliphatfs How would a DAP client use that input-request?

[eliphatfs]

For example, VS Code may have some menu option to enter the std input sending mode, and under that mode when user hits Enter a input request is issued with the line of content input previously in the data field.

[weinand]

@eliphatfs thanks for your answer

Using a menu action is not very discoverable for users: an interactive (command line) program typically prompts the user via stdout and then reads data on stdin. Requiring that the user then uses a menu action is not very intuitive.

IMO, input cannot be separated from output. That makes a console/terminal a good choice but with that we are running into the problem that both the debug REPL and the program want to read input (actually with feature request #231 there is even a third component, the debugger that wants to read input).

If we could find out that a program reads from stdin, then we could bring that information to the client so that the debug console UI could show a different prompt to indicate which component is currently reading input. But I'm not aware of a way to do this.

[roblourens]

To me, running the program in the terminal when you know that you need to give input to stdin doesn't seem like such a bad workaround. Some other options I can think of:

• An option to switch the debug console from debug repl to stdin, as a toggle button or extra option in the dropdown
• An option in the launch config which makes the debug repl only for stdin
• Somehow detect when the program wants to read from stdin, and send stdin from the debug console (pretty sure this isn't possible in a practical way for the DA or client)

If I had to pick one, I would add a toggle button to the debug console input that switches to "stdin mode". But, my experience with search leads me to suspect that people will click it by mistake and get confused. I'm not sure it's that large of an improvement over using the terminal.

[mfussenegger]

Just to put this on the radar as an option:

vscode-lldb supports stdio redirection as part of the launch configuration: https://github.com/vadimcn/vscode-lldb/blob/master/MANUAL.md#stdio-redirection

[yannickowow]

Not sure if it would behave as you want, but my current workaround for this is as follows (debugger is GDB). As you said, input cannot be separated from output.

• Create a "stdio" PseudoTerminal - Takes focus + foreground when created (might be undesired...)
• When user writes in this terminal, send a stdin custom request (should be defined in DAP instead)
• In a stdout event, write output in the Pseudoterminal

For some debuggers (like GDB), REPL is not working if an input is requested, since debuggee is still in a Running state. Also, you can not guess when you need to "unlock" it. Terminal is then always in a "available" state

[connor4312]

If I had to pick one, I would add a toggle button to the debug console input that switches to "stdin mode".

I was thinking about this over the weekend. A simple program that reads single characters from stdin would work fine with this, but more complex applications have more interaction, and more than can be represented in the current VS Code Debug Console. Even given an omnipotent Debug Console view, interleaving complex stdin/out with REPL might not be possible -- for example, imagine a rich curses-based CLI. In terms of UI, I would imagine instead a split view with the traditional REPL on one side and a terminal for stdin/out on the other.

Somehow detect when the program wants to read from stdin, and send stdin from the debug console

This is the hard part, and I don't think it's possible universally (the closest would be using strace to monitor for reads, but that's Linux-only.. and complex.) Having a toggle button in the debug console would mostly avoid the need for detection, since it can be present all the time without adding a bunch of visual clutter.

Having a REPL separate from stdio may be something that users find generically useful. I would turn on when working with development servers that like to log their incoming requests, for example. If this is just a general feature, that would also avoid the need for specific detection or signaling. Though this is also possible in recent releases of VS code by dragging the terminal to create a spit view with the Debug Console.

[weinand]

Thank you all for the comments.

After reading and contemplating about the comments again, I see two important messages:

• showing program input/output separate from a REPL is preferred because multiplexing REPL input/output and program input/output in a single "debug console" would most likely be a technical challenge and result in a UI that is confusing for users.
• supporting a debuggee's rich CLI (e.g. curses-based) in a faithful way is only possible if native mechanisms are used: e.g. the program runs in a "terminal emulator", communicates via a "pseudo-tty" and sees a "control terminal". Using an intermediary (debug adapter and DAP protocol) between the debuggee and the debug-console will worsen the experience.

From this I conclude that there is no strong need to have a DAP input request because the existing DAP concepts are sufficient to implement a good UI experience.

@eliphatfs @connor @roblourens @mfussenegger @yannickowow what do you think?

[roblourens]

I agree

[weinand]

Closing, since there are no objections.