Could RunInTerminal be supported?

[ckipp01]

So digging around I think the answer is yes, in theory it could be supported, but it's not currently. However, I wanted to check to see if that's the case or if this has been explored at all yet during development.

Some back story

So the context for this is current for some clients that utilize Metals to run/test/debug can't support colors in the debug console. When we first hit on this I added in a setting that can be used that just strips the color. This is most relevant when you are running tests. This works fine, but as you can imagine the output then in the dap console in a client that doesn't support color looks like this:

Instead of the nice colors you get in the terminal or in a console like VS Code has that supports colors:

I started to look into how I could better support colors in nvim-metals which uses nvim-dap and when speaking to the nvim-dap maintainer the topic of RunInTerminal came up. This would cause the output to be in the integrated terminal of Neovim for example (or other editor that supports integrated terminals) and the color codes would be correctly interpreted.

The debug console vs RunInTerminal

I'm still digging into this a bit, but from my understanding when a client says that it supports supportsRunInTerminalRequest during init the RunInTerminalRequest request can be used which will then start an integrated or external terminal session and then everything following will be sent there by the client instead of the debug console.

Taken from the overview page

launch request: the debug adapter launches the program (“debuggee”) in debug mode and then starts to communicate with it. Since the debug adapter is responsible for the debuggee, it should provide options for the end user to interact with the debuggee. Basically there are three options how the debuggee can be launched. Two of the options are available to the debug adapter via the RunInTerminal request.

• the debug console: this is an interactive REPL environment which allows the user to evaluate expressions in the context of the debuggee. Program output shows up in the debug console too, but the program cannot read input through it (because of the REPL functionality).
• an integrated terminal: this is a terminal emulator integrated in the development tool. It supports the usual terminal control codes and supports reading program input.
• in an external terminal: similar to the integrated terminal, but the terminal runs outside of the development tool.

Do you have any idea if there would be limitations in supporting this, or has this been looked into at all yet?

[adpi2]

Thank you @ckipp01 for opening this discussion. I never heard about this request before and it is an interesting one.

According to the spec, it is a reverse request, so it is sent by the debug server (Bloop or sbt) to the debug client (VS Code or nvim) for the client to start the debuggee in a terminal. It solves the problem of color support, as you mentionned, but also it makes it possible for the debuggee process to read inputs from the user. That would be really nice to have, so yes I think it is worth looking into it.

One thing that is not clear to me is how the debug server decides if it should start the debuggee itself or if it should send a RunInTerminal request to the client. For instance, in VS Code, it is often better not to run the debuggee in a terminal so that all the logs go to the debug console, except if the debuggee needs to read input from the user. But, in nvim, the debuggee process should always start in a terminal.

In terms of implementation there may be one difficulty: Currently the debug server needs to read the socket address of the the debuggee in the first outputed line of the process:

Listening for transport dt_socket at address: 43031

But I think it is not possible to connect to a started process and to read its old output. As an alternative the debugger can find an available port and assign it to the debuggee.

[ckipp01]

One thing that is not clear to me is how the debug server decides if it should start the debuggee itself or if it should send a RunInTerminal request to the client.

I think it should sort of rely on the client to tell it or not? I guess in the Metals scenario I'd expect something like this?

sequenceDiagram
    dap client->>+metals: I want to runInTerminal
    metals->>+debug server: forwards the request with a flag or something
    debug server->>+debug server: starts up
    debug server->>+dap client: based on value passed in either sends runInTerminal request or not
    debug server ->dap client: normal communication continues

Loading

In terms of implementation there may be one difficulty: Currently the debug server needs to read the socket address of the the debuggee in the first outputed line of the process:

Maybe I'm misunderstanding, but I sort of just thought it was a switch, like the debug server shoots the RunInTerminalRequest and then everything else just continues as normal?

[adpi2]

The debug server sends the RunInTerminalRequest for the client to start the debugee, but then it still needs to connect to it (to set the breakpoint, read the stack frames, submit the expression and all). The debuggee is just the application process, it does not know anything about DAP. Also the terminal does not replace the debug console completely, the user still needs it to submit expression to evaluate.

[tgodzik]

I wonder I wonder if we could add agentlib setting, it would then be run in the terminal and we could do an attach request then?

One thing that is not clear to me is how the debug server decides if it should start the debuggee itself or if it should send a RunInTerminal request to the client. For instance, in VS Code, it is often better not to run the debuggee in a terminal so that all the logs go to the debug console, except if the debuggee needs to read input from the user. But, in nvim, the debuggee process should always start in a terminal.

For VS Code that seems to be set in launch,json, would need to forward the option from the client. Maybe it can be present in configuration of StartDebuggingRequest ?