Support execution of debugger commands

[vadimcn]

Most gdb/lldb-bsed debug adapters provide a way to execute debugger commands from Debug Console, usually by introducing some prefix to disambiguate commands and expressions. Would be nice if there was an explicit support for this in DA (and, eventually, explicit UI in DAP clients).

Somewhat related to #84, which would be nice to have too.

[puremourning]

also vaguely related: #45

[weinand]

Today DAs implement that feature on their own by introducing some "escape" syntax for debugger commands so that they can be distinguished from REPL commands. IMO this approach makes sense because the DA knows best how to integrate debugger commands into the REPL syntax.
What would be the benefit of introducing DAP for executing commands?
@vadimcn do you have a specific UI in mind where REPL and debugger commands are separated?

[weinand]

A somewhat related request: #216 Proposal: add a request for standard input

Reading program input would be a third component that is interested in reading user input from the debug console (see
#216 (comment))

[lanza]

Today DAs implement that feature on their own by introducing some "escape" syntax for debugger commands so that they can be distinguished from REPL commands. IMO this approach makes sense because the DA knows best how to integrate debugger commands into the REPL syntax.

This is the same discussion we had years ago in #45. Terminal emulators and CLI debuggers speak ANSI escape codes and the DAP console does not. If you don't understand the implications of this please read this series of blog posts from Rich Turner. Rich clearly explains why a few teams at Microsoft went to extraordinary lengths to support this for the windows console.

But at any length, you've now had the developers of numerous lldb related DAP extensions and DA host implementations request this feature independently. I think that merits further consideration of the idea.

[vadimcn]

My request is motivated by a certain amount of impedance mismatch when commands and expressions are multiplexed into debug console:

• One needs to invent an escape sequence that does not clash with the target language's syntax (which may not even be known ahead of time for multi-language debuggers like lldb). This also makes it difficult to create a generic UI in IDEs for automatic execution of before-/after- session commands.
• Commands may take a long time to execute and may spew out lots of output, which fits poorly with how EvaluateResponse is designed.
• VSCode tries to syntax-color (and complete?) debugger commands using target language's syntax.

[weinand]

@lanza I think I understand "ANSI escape codes" and the implications of not having them.

VS Code's integrated terminal has full support for ANSI escape codes (and much more) and there is rich extension API to talk to the integrated terminal. We have no plans to duplicate any functionality available for the integrated terminal in the debug console.

What I do not yet see is how VS Code's generic debugger UI could "wrap" the integrated terminal and connect it via new Debug Adapter Protocol with a command interpreter running in the DA. Do we really need a new abstraction for this or could a debugger extension just use the existing integrated terminal API directly?

Before we add new protocol for this area, we should really have a sample extension implementation that shows how a useful client UI would look like and how a generic client implementation would profit from some new standardised DAP protocol.

In #216 (comment) we agreed why it doesn't make sense to add new DAP protocol for handling program input. IMO the same arguments apply to new DAP protocol for executing debugger commands.

/cc @connor4312 @roblourens

[weinand]

@vadimcn what is your proposal for new Debug Adapter Protocol?
How would that protocol be used in the VS Code client?
Would VS Code define the "prefix" to disambiguate commands and expressions in the debug console?

/cc @connor4312 @roblourens

[connor4312]

This came up a year or two ago. My position then was against having a standard escape sequence or format that commands should come in, as for example a list debugger might like to use (copy expr) where the js debugger uses copy(expr).

VSCode tries to syntax-color (and complete?) debugger commands using target language's syntax.

Clients complete this through the DAP completions request. Perhaps we add a new CompletionItemType called "debugger" or something along those lines in order for UIs to show what debugger commands are. A client, or user, could request completions for an empty string to retrieve all relevant commands.

However, as Andre said, in this issue I'm still not clear on the requested UI for this feature. Is distinguishing what's a "debugger command" in the completions list sufficient?

[weinand]

As pointed out by @lanza and @connor4312 there was already a related discussion in 2019.

[roblourens]

I agree that the DA is in a better position to handle this in general, maybe except for the syntax highlighting. But that is only based on the language of the active editor anyway, so it's always a guess that may not be accurate.

[weinand]

Thanks everybody for input.

Since no sample debugger command UI is available (or has been proposed), I don't think that we are in a position to propose a DAP extension for "execution of debugger commands".

I will close this item for now and I suggest that we first try to address some of the identified pain points or limitations:

• let's support "debugger commands" in DAP's completions request by adding a new CompletionItemType called debugger.
• support syntax highlighting of "debugger commands" in the debug console.