Support for attaching a command interpreter to a pty slave

[lanza]

I work on lldb and would like to provide functionality for lldb to be handed a pty slave and then attach it's standard command interpreter. Note that we'd like this functionality in addition to the Debug Console prompt as that is only used for expression evaluation.

Within lldb-vscode, we just offer the user to prefix their Debug Console input with a literal backtick to pass the command to the CommandInterpreter class. This is a clumsy work around. It lacks completion, history, and the rest of the editline/readline repertoire that command line users are used to.

A temporary workaround I've done is to just launch lldb-vscode in the terminal and attach the CommandInterpreter to the standard stdin/out/err pty slave and then listen to the DAP communication over a socket connection. But this is just another clumsy workaround.

We envision the server responding to initialize with supportsAttachingCommandInterpreter: true or a similar packet to which the client would respond by doing the ptyopen dance and handing the slave to the server via commandInterpreterPty: "/dev/pty0123" and then opening a new terminal emulator attached to the master. The server could then open("/dev/pty0123", "rw"); and dup to stdout and stderr to have a full fidelity command line debugging experience on top of the lovely integrated GUI experience.

[weinand]

Thanks for suggesting a new feature.

However, I do not fully understand what you are trying to achieve...
So here are some questions:

• "lldb-vscode" is a command tool like "lldb" that uses the VS Code debugger as its UI, correct?
  But then I got lost.. could you provide some screen recording that shows "lldb-vscode" in action?
• when you talk about "server" you mean "debug adapter" and with "client" you mean "VS Code", right?
• If my last assumption is correct, then VS Code needs to probe for a "supportsAttachingCommandInterpreter" capability returned by the debug adapter. This means that your new feature is not only a DAP extension but requires code in VS Code too. Shouldn't we then move the discussion to the VS Code repository? You are actually asking for a new VS Code feature (which might require a DAP extension eventually).

One additional comment:
in the proposed protocol you are talking about Unix paths and sys calls. Please be aware that DAP operates on a more abstract level since it is OS agnostic. A VS Code implementation does not want to deal with OS differences. If there are any, they need to be handled in the debug adapter.

[lanza]

in the proposed protocol you are talking about Unix paths and sys calls. Please be aware that DAP operates on a more abstract level since it is OS agnostic. A VS Code implementation does not want to deal with OS differences. If there are any, they need to be hanudled in the debug adapter.

Yup, our implementation (lldb-vscode) works on both. I just refer to posix API calls because I have them memorized and have to look up the full win32 ones. But we offer full support for both platforms. I'm not proposing a specific implementation, just using the linux syscalls to demonstrate the idea.

lldb-vscode is a C++ program that just loops over STDIN for DAP packets. e.g. in simplified pseudoish code

int main() {
    while (true) {
        llvm::json json = readJSON();
        dispatchJsonHandling();
    }
}

Nothing exciting there. But within the program there is a function that can run a repl loop. Again in psuedoish code:

void start_repl_loop(int file_descriptor) {
    while (true) {
        read_line();
        eval_line();
        print_result();
    }
}

Currently, that function is unused since lldb-vscode is launched like any other DAP implementation and has STDIN and STDOUT connected for DAP packets.

This request is for the DAP implementation to tell the host that it has a function like start_repl_loop that can provide command line functionality if offered a pty that will be attached to a terminal emulator. So in response to the initialize packet the DAP implementation would say supportsCommandInterpreter: true.

If the host tool (e.g. VSCode or emacs dap-mode or vim-vimspector or neovim) supports this functionality, it will ptyopen a new pty slave/master pair, send the slave filepath to the DAP implementation and attach the pty master to a terminal emulator. The DAP implementation will open the file and call start_repl_loop on it.

The ultimate result is that you have both the standard gdb/lldb/pdb/jdb/visual-studio debugger/etc command prompt AND the GUI integration for any implementation that supports this option.

"lldb-vscode" is a command tool like "lldb" that uses the VS Code debugger as its UI, correct?
But then I got lost.. could you provide some screen recording that shows "lldb-vscode" in action?

lldb-vscode is nothing special. It's a DAP implementation. The program in the package.json is lldb-vscode and it handles DAP packets the same as any other DAP implementation. It just has a function that can open a REPL that is currently unused since the DAP and VSCode do not offer this functionality.

If my last assumption is correct, then VS Code needs to probe for a "supportsAttachingCommandInterpreter" capability returned by the debug adapter. This means that your new feature is not only a DAP extension but requires code in VS Code too. Shouldn't we then move the discussion to the VS Code repository? You are actually asking for a new VS Code feature (which might require a DAP extension eventually).

Not quite. This is a DAP feature. VSCode would just implement it. If I choose to implement this in vim-vimspector and nobody ever touches it for VSCode it would still require both sides to agree on the DAP communication of this functionality.

[puremourning]

If I understood this correctly, this would allow the DAP client to present a true UI to the command-line-debugger. This is a really nice feature of graphical debuggers: yes the UI is nice, but power users know how to do things using the debugger CLI quickly.

As a power user, that's really attractive to me. And as the author of Vimspector, I'd look to somehow make this possible with Vim's built-in Terminal. Though if I'm honest, I don't know how to make that happen (yet).

OTOH I wonder how general it is. I mean for a given DAP server, how many things could I do in the lldb, gdb, a.n. other, CLI that would break the state and/or behaviour of the DAP wrapper (e.g. MIEngine). This is already a problem for some adapters that try this. Again, referring to vscode-cpptools, if you happen to set certain types of conditional breakpoint via the "REPL" interface, it breaks the debugging session.

I think I'd be in favour of this protocol addition if there were a number of server authors (and perhaps client authors) that would implement it consistently and robustly.

[lanza]

As a power user, that's really attractive to me. And as the author of Vimspector, I'd look to somehow make this possible with Vim's built-in Terminal. Though if I'm honest, I don't know how to make that happen (yet).

Yea, this is something that will need to be implemented in every host. Luckily VSCode and neovim are very openly maintained. Some means to pass around ptys and mapped terminal buffers will be necessary.

The actual final implementation strategy could be very different. This was just something another lldb developer and I spoke about while considering implementing the command line interpreter for our lldb-vscode binary. The command line interpreter tools will need a fd that reports back true to isatty. Hence the suggestion to hand off a pty path for open.

OTOH I wonder how general it is. I mean for a given DAP server, how many things could I do in the lldb, gdb, a.n. other, CLI that would break the state and/or behaviour of the DAP wrapper (e.g. MIEngine). This is already a problem for some adapters that try this. Again, referring to vscode-cpptools, if you happen to set certain types of conditional breakpoint via the "REPL" interface, it breaks the debugging session.

I think I'd be in favour of this protocol addition if there were a number of server authors (and perhaps client authors) that would implement it consistently and robustly.

This is a weird bias towards young projects and the short-term. A properly done debugging interface could be a many decade solution that all debuggers could grow to stability against. It should be done right and not focused on today's bugs. Visual Studio, Xcode, Clion, Android Studio, IntelliJ, Eclipse etc all offer command line debugging integrated into their GUIs.

I'm not sure of the long term goals of the DAP authors. But if it's completion and feature parity then this functionality seems like a requirement.

[weinand]

@PavelSosin this project is about the Debug Adapter Protocol. Please refrain from making questionable statements about unrelated topics.

[puremourning]

This is a weird bias towards young projects and the short-term.

That’s a reasonable criticism. As I said I love the concept of power we can expose, but I worry that the robustness could ultimately hinder UX. but if the community are behind it, then I have no fundamental objection, other than considering whether the protocol wants to support running the DA on another’s host, in a container, etc.

Having said that @weinand is correct to point out that UX in that sense is somewhat orthogonal tot he protocol definition. Though a protocol without real use cases isn’t strictly a solution to anything ;)

[puremourning]

If I'm understanding @PavelSosin correctly, the concern is that by including in the protocol such a concept as a file descriptor, or pseudo terminal, then that bakes in an assumption that the client and server share some common hardware or software or filesystem. I think that's a reasonable concern (though not one that particularly bothers me), but it begs a wider question about the expected use case for the protocol: is there an inherent assumption that the client/server run on the same machine? There is in LSP (you pass the parent PID, IIRC, and there are some filesystem assumptions), and I also think there are for practical reasons in DAP (e.g. runInTerminal and suchlike). So perhaps that's a wider question.

Assuming that is the question/concern, I suspect it could have been expressed better. If it's not, then I'm struggling to see the relevance of most of what was said.

[lanza]

Having said that @weinand is correct to point out that UX in that sense is somewhat orthogonal tot he protocol definition. Though a protocol without real use cases isn’t strictly a solution to anything ;)

Yea, the implementation into VSCode's GUI is an entirely different feature suggestion I'll have to do over there. But the feature will require the DAP to support it in the first place. Their implementation will be muddied a little bit as there already is a Debug Console. Maybe they can move that to a Variable Evaluation pane and repurpose the Debug Console being that what I'm proposing is more properly a "Debug Console."

[puremourning]

@PavelSosin even if your baseless statements about what "99% of investments" are used for are accurate, they are irrelevant to the discussion.

The last areas where low level programming is applicable are compiler and driver development.

This is simply untrue and shows a level of ignorance that I find deeply saddening.

[weinand]

@lanza there is no need to communicate to a DA via stdin/stdout. Using a socket instead is possible and part of VS Code's extension API. The Java debugger and other debug extensions use this approach.

When starting a debug session your extension code could launch the DA of lldb-vscode in the integrated terminal and pass a port number for the DAP communication. VS Code would then connect to this port.
Stdin and stdout would be available for the user to interact with your command interpreter.
VS Code's debug console would be still available as a REPL.

Why do you need a protocol addition for this?

[weinand]

@lanza please find another relevant question three comments above. Sorry that it drowned again...

[puremourning]

@weinand Regarding this:

When starting a debug session your extension code could launch the DA of lldb-vscode in the integrated terminal and pass a port number for the DAP communication. VS Code would then connect to this port.

The issue I have with this is this part:

your extension code

The problem is that this extension code won't exist for all-but-one of the actual clients. By integrating into the protocol, this allows all clients to benefit from this feature without having to write debug adapter-specific code, which I for example (as one person in my evenings and weekends) can't do for something like vimspector.

I think the use case is general (a REPL interface to the debugger), and has been implemented (badly) by some DAs using the evaluate request already. Perhaps we can argue about the implementation (pty slave or not, etc.), but can we agree on the generality of the use case?

Arguably useful contribution part ends here.

---

@PavelSosin You have to realise that there is a real use case for convenience of integrated debugging and power-user command interface, surely? Your own personal experience of cloud IDEs, and their use cases, is potentially useful input but not the only input and certainly not the only use case. It confounds me that you don't see that.

Moreover, this remains an optional feature. If your objection is that you can't implement it in your cloud-based whatever, then don't. I suspect that you can't implement the processId argument of the initialise request of LSP either, right?

interface InitializeParams {
	/**
	 * The process Id of the parent process that started
	 * the server. Is null if the process has not been started by another process.
	 * If the parent process is not alive then the server should exit (see exit notification) its process.
	 */
	processId: number | null;

---

FWIW, my personal opinion, which remains as irrelevant as yours, is that the worst possible IDE is one in a web browser. This is made completely unusable by being in "the cloud" as you put it. In my company this would be laughed at. Again, irrelevant to the discussion.

As a professional software engineer working with real mission critical systems, a good integrated debugger is especially useful to productivity. It is also very useful to have power user features as well, allowing a broad range of possible use cases across a broad range of programming and testing environments. I doubt there are a lot of game programmers using cloud-based IDEs.

[weinand]

@puremourning Debug Adapters were never designed as end-user visible tools. They are an implementation detail that "adapts" a generic debugger UI with a specific real debuggers via an abstract wire protocol.

Debug Adapters don't have an end user command interpreter because typically the "real debugger" has that and I see no need to duplicate that.

You said:

By integrating into the protocol, this allows all clients to benefit from this feature without having to write debug adapter-specific code, which I for example (as one person in my evenings and weekends) can't do for something like vimspector.

Since no DA has a command interpreter, it would be necessary for individual debug extensions to add one to the DA before they could profit from the generic functionality introduced with this feature.

But if the DA has to be changed anyway, then why not change the extension in the way I've described above? And if we see widespread adoption of this approach then we can add this feature to the Debug Adapter Protocol.

But I'm hesitant to add a new feature to the DAP that is not heavily requested.

[weinand]

@PavelSosin could you please move your monologue to a new issue as it is unrelated to the topic at hand. Thanks.

[puremourning]

@weinand

Debug Adapters don't have an end user command interpreter because typically the "real debugger" has that and I see no need to duplicate that.

I would agree except that:

• the "real debugger" backs the DA, and this is just exposing that to the end user (by allowing it in the protocol
• the best (reference?) c/c++/etc. debug adapter (Microsoft's vscode-cpptools) already exposes this "real debugger" in the "Console" by allowing you to snd arbitrary commands -exec <command>

So there's clearly a real use case for it (it's already in use).

They are an implementation detail that "adapts" a generic debugger UI with a specific real debuggers via an abstract wire protocol.

I understand that entirely.

then why not change the extension in the way I've described above?

For the reason I mentioned above: this requires that client code is written to handle this per-debug-adapter which makes it no longer and abstract protocol, or that the "UI" is no longer generic.

But I'm hesitant to add a new feature to the DAP that is not heavily requested

Couldn't agree more. OTOH I'm strongly opposed to DA authors adapting to only work with VScode because the protocol limits the features they can expose that their users require. It's certainly a balance. As I said earlier:

I think I'd be in favour of this protocol addition if there were a number of server authors (and perhaps client authors) that would implement it consistently and robustly.

[weinand]

@puremourning the best way to spark interest in such a feature is by implementing and then marketing it. Where is the screen recording that shows this killer feature for "lldb-vscode"?

It took me a long time to grasp what this feature is all about (and I'm not really sure that I've understood it... @lanza need to confirm this first)

You complained:

"client code needs to be written to handle this per-debug-adapter"

Client code has to be written in any case because 99.99% of all DAs don't have command interpreters. So they need to be written first. The DAP protocol addition does not help with that.

The DAP protocol addition (and a client implementation of it) only helps to launch a DA in the integrated terminal and make the debugger UI to connect to it. These few lines of code are not a big deal. And everyone who wrote these lines will gain a lot of experience how the DAP addition will have to look like.

That's the approach how we typically extend DAP: first we implement the new feature as an extension and then we try to understand the limitations of that approach and how a DAP addition could fix this.

Adding a DAP protocol addition first and then hoping that someone is using it, has never worked.

BTW, before discussing details like this DAP addition, I would have expected to find feature requests filed against the clients (e.g. VS Code) that actually ask from an end users perspective, e.g. "support a CLI for debuggers". But I cannot remember that I have seen such a request...

[puremourning]

Client code has to be written in any case because 99.99% of all DAs don't have command interpreters. So they need to be written first. The DAP protocol addition does not help with that.

Apologies, perhaps I wasn't clear. When I say client code, I meant debug adapter client, i.e. vscode, vimspector, something else. I've no association with lldb whatsoever. I write vimspector, which is a debugger UI using DAP to communicate with debug adapters. I guess what I would say my position is:

• I think command line/repl interface to the actual underlying debugger is a good feature to have for a lot of debugging systems
• I would like that to be available in vimspector for any DA that makes it possible

If the protocol were to say: These messages are how you implement this feature is a completely debug-adapter and language-agnostic way, then as a debug adapter client author, I can write the code once (to the spec) and work with any debug adapter that implements it. If adapters are forced to go around the protocol by writing an "extension" (which I understood to mean a vscode-only piece of javascript), then only those clients (vscode) for which this "extension" has been written can benefit. THat's all I was saying about whether or not it warrants being in the protocol.

You complained.

I wasn't complaining :) Just contributing to the discussion. Apologies if you got that impression !

As the author of a client implementation it matters to me how much work is required to support each debug adapter. I would like to write to the specification and for any debug adapter to just work. I was under the impression that was a goal of having the protocol.

That's the approach how we typically extend DAP: first we implement the new feature as an extension and then we try to understand the limitations of that approach and how a DAP addition could fix this.

Understood. If that's the plan then I'm all for it.

Just so we're clear, where you say "extension", do you mean an extension to the protocol, or an extension to vscode via some javascript or other ?

Adding a DAP protocol addition first and then hoping that someone is using it, has never worked.

Again, I agree. The reason I'm contributing to the debate is that if, say vscode-lldb implemented such a feature, and it were part of the protocol, I would implement support for it in vimspector, as I see the value of it. Following this repo is the only way for me to know about upcoming changes to the protocol that I need to implement.

[weinand]

@puremourning you said:

I think command line/repl interface to the actual underlying debugger is a good feature to have for a lot of debugging systems

I agree with the "repl interface to the actual underlying debugger" but the "command line interface to the debugger" sounds a bit strange because the purpose of DAP is to connect a (graphical) debugger UI with a non-graphical debugger backend.

Using DAP to connect one debugger CLI with another debugger CLI was at least not the "design center" of DAP. So before we extend the DAP for this, we should make sure, that there is enough value and interest in that feature.

VS Code's builtin node.js debugger supports REPL and Intellisense in VS Code's debug console, but no one has ever asked to interact with the debugger via a CLI. In the VIM community that might be different, but the main target for DAP are tools with graphical UIs.

---

When I said "extension" I was referring to "VS Code" extensions or Eclipse plugins.
However, "protocol extension" makes sense too, because it is always possible to introduce private DAP protocol messages in an ad-hoc way if an (VS Code) extension needs to talk to its DA outside of the protocol.

[lanza]

My backdoor implemented lldb-vscode

Xcode's implementation

Visual Studio's immediate Window Note that it also has the command window which does more

windbg's command prompt (the prompt that says 0:000>)

Clion/Android Studio's command prompt

@lanza there is no need to communicate to a DA via stdin/stdout. Using a socket instead is possible and part of VS Code's extension API. The Java debugger and other debug extensions use this approach.

When starting a debug session your extension code could launch the DA of lldb-vscode in the integrated terminal and pass a port number for the DAP communication. VS Code would then connect to this port.
Stdin and stdout would be available for the user to interact with your command interpreter.
VS Code's debug console would be still available as a REPL.

Why do you need a protocol addition for this?

These are the features I'm trying to match. In the first picture, I did what you suggested. I launched lldb-vscode via createTerminal and attached the command interpreter and then listened via a socket.

The problem with this is that it's, as @puremourning stated above, an adapter-to-host specific hack. The DAP doesn't support this and I'm shoe horning the feature in to make it work. If I want this feature in vimspector I have to shoe horn it there, too. If I want it in Visual Studio's debug adapter host I would require a third makeshift hack. This is the point of the protocol. To remove these implementation burdens. Every adapter should implement it once and every host should implement it once and it should work.

VS Code's builtin node.js debugger supports REPL and Intellisense in VS Code's debug console, but no one has ever asked to interact with the debugger via a CLI. In the VIM community that might be different, but the main target for DAP are tools with graphical UIs.

I think you're confusing the demographic. This isn't a vim vs VSCode thing. This is a JavaScript vs native thing. Developers that write native code expect this functionality. ALL Apple platform developers have lldb's command prompt trivially available as shown in the Xcode image above. All of Microsoft C++ developers have multiple options for command prompt + GUI debugging via WinDbg and Visual Studio. If you do native development in Android then Google's Android Studio offers lldb's command interpreter. And if you step into the GNU world then you have a thousand more examples of native code IDEs with command interpreters, the simplest of which could be the cgdb tool.

I'm shocked by the statement "no one has ever asked to interact with the debugger via a CLI." This is a flagpole feature request for the developer tooling I'm working on for Facebook/Oculus. lldb's feature set is such a drastic superset of the DAPs that it would be near impossible to adequately suit all our user's needs without the command interpreter.

[lanza]

So I don't use the https://github.com/Microsoft/vscode-cpptools plugin. But I just installed it to try it out. They ALSO backdoor the command interpreter via passing -exec thecommand in the Debug Console in order to execute lldb commands. I'm going to guess that they would also be in support of a properly implemented command interpreter.

[weinand]

@lanza thanks for providing that detailed CLI overview.

So let's get some stakeholders from the C# and C++ debuggers to the table:
@andrewcrawley @gregg-miskelly @pieandcakes what's your take on this feature request?

[walter-erquinigo]

I want this feature!

I work for Oculus and we do a lot of non-web native development: games, operating systems, frameworks, hardware controllers, etc. Besides, many of our developers are trying to move to VSCode, which is a very cool IDE.

In terms of debugging, something quite relevant is accessing the broad range of commands that LLDB offers, which are beyond what the VSCode debugger UI supports through the DAP protocol:

• memory debugging
• disassembling
• register debugging
• scripting (yes, it's common to load a python script from LLDB that automates some workflow)
• symbol lookup
• module debugging
• etc.

What I mentioned here are some of daily tools native-code developers use when debugging and these are not just for power users. It can't be expected to have such features in the VSCode UI, but there should be access to them through a CLI at least.

I think supporting the PTY or creating a REPL protocol in the DebugConsole are reasonable implementations.

[pieandcakes]

For the C++ extension, we rolled a special REPL command where if the command was prefaced with -exec we would forward the command to the underlying debugger without additional parsing. I think with this proposed change, it would alleviate users from having to type -exec in front of every command sent through the REPL window.

[walter-erquinigo]

Also, supporting completion seems like a must to me. Many commands can be long, not easily memorizable, and have typos when written. A full-fledged REPL with history and completion would boost productivity.

[gregg-miskelly]

From the VS IDE perspective: VS doesn't have a 'Debug Command' window. So there wouldn't be a good way to consume this in VS. VS does have a command window all up which isn't debugging specific. But the way to plug into that is very VS specific, and doesn't have a reasonable way to bridge.

For the C#/C++ DA perspective: To add onto what @pieandcakes mentioned, I think in most cases '-exec <command>' works pretty well -- it can be nice to not have to switch back and forth between two windows. But there are some cases where you want to type a bunch of commands where it would be nice for something more modal. Of course we could implement this in the DA itself by supported some sort of '-CommandMode enter'. But a separate window might be more discoverable. The other case that works a bit better is if the underlying debugger prompts the user when a command is executed. Today the C++ DA doesn't handle this well.

[walter-erquinigo]

@gregg-miskelly , I don't think that -exec provides a good developer experience. If you enter the LLDB REPL and type help, you'll find tens of commands, each of them having some additional tens of commands. Without proper completion and history, using the CLI through a mechanism like -exec might make some users avoid most of the time this functionality.

[gregg-miskelly]

@a20012251 the protocol already supports completion in the debug console. See CompletionsRequest.

[gregg-miskelly]

I should also add: I believe VS Code already supports history in their implementation of the debug console.

[lanza]

Right, but it's a backdoor. The spec itself says this prompt is for evaluating expressions in the context of the current stack frame. It's not a prompt for debugger commands. The packet sent is the same packet as the one sent for hover evaluations.

I don't think it's a contentious statement to say that the Debug Console's backdoored command prompt implementations are a sign of a problem. Here are all the ways the features I am requesting are hacked into the implementations:

• vscode-cpptools - Prefix the command with -exec e.g. -exec target list
• vscode-lldb - The specs is actually ignored and evaluate actually evaluated the lldb command. You must prefix your Debug Console command with ? in order to get the spec's evaluation requirements.
• lldb-vscode - Prefix the command with a backtick. 'target list.
• code-debug - Same as vscode-lldb, ignores the spec and provides the debugger command prompt instead.
• My own implementation - As @weinand mentioned above, createTerminals lldb-vscode, attaches command prompt and then listens via a socket to provide the actual lldb command prompt.

So we have five tools with four unique approaches to circumventing the shortcomings of the DAP. All of which technically violate the specification in order to do so.

[gregg-miskelly]

I think that depends on if we have a prominent DA client that wants to offer a separate REPL window (or a different mode in their 'debug console').

If yes - we should extend the protocol.
If no - maybe all that is required is clarifying the documentation for the current evaluate response to indicate that really the DA is allowed to interpret the text however they like.

[weinand]

A "debugger command console" (my term for this feature) is not on the VS Code roadmap.
This could be changed. But for this we would need some interest showing up as VS Code feature requests and issues.

[yannickowow]

Right, but it's a backdoor. The spec itself says this prompt is for evaluating expressions in the context of the current stack frame. It's not a prompt for debugger commands. The packet sent is the same packet as the one sent for hover evaluations.

Sorry if I dig this from too far, but is considering LLDB (or in my case, GDB) a REPL is a non-sense?
Since, for example, GDB MI (and probably LLDB-MI ?) supports --thread and --frame reference based on currently selected stack frame, and GDB-MI supports "complete" command, I did suggest it can be used as a prompt for commands.
But, in my case, this implementation also break support for "Evaluate" when using from editor context-menu. In my case, it would be perfect if uses another context than REPL (such as watch?)

[lanza]

Right, but it's a backdoor. The spec itself says this prompt is for evaluating expressions in the context of the current stack frame. It's not a prompt for debugger commands. The packet sent is the same packet as the one sent for hover evaluations.

Sorry if I dig this from too far, but is considering LLDB (or in my case, GDB) a REPL is a non-sense?
Since, for example, GDB MI (and probably LLDB-MI ?) supports --thread and --frame reference based on currently selected stack frame, and GDB-MI supports "complete" command, I did suggest it can be used as a prompt for commands.
But, in my case, this implementation also break support for "Evaluate" when using from editor context-menu. In my case, it would be perfect if uses another context than REPL (such as watch?)

I'm sorry but I don't understand what you're asking.

[yannickowow]

I was just asking if using directly debug commands in this Debug Console is really "out of spec" or not. Since GDB has a way to complete commands, you can fulfill "CompletionsRequest" with GDB one's. In the same way, GDB "REPL" is not really something relevant (in my opinion...)

Also, you said:
The packet sent is the same packet as the one sent for hover evaluations.
It is not really true, since you have a flag repl or hover depending on your current context.

Correct me if you don't see this thing like me, but, to me, changing the "Evaluate In Debug Console" context (using watch, a new one or ask the debuggee to add a prefix when executing this action (example: print)) in Editor's context menu and use "Debug Console" as debugger command console can be "sufficient".