Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request]: Support for attaching a command interpreter #323

Closed
lanza opened this issue Dec 20, 2020 · 1 comment
Closed

[Feature Request]: Support for attaching a command interpreter #323

lanza opened this issue Dec 20, 2020 · 1 comment
Labels
Blocked Needs more information, can't be supported in DAP, etc. enhancement New feature or request

Comments

@lanza
Copy link

lanza commented Dec 20, 2020

Almost two years ago I made a feature request on MSFT's DAP repo requesting for feature support for the DAP to allow the client to offer a terminal to the server for which it can attach it's command interpreter. You chimed in at the time in support of the idea in theory with reservation towards the popularity of the idea. Some months after the post I stopped working on lldb and IDE tooling and let the idea just rot since I wasn't able to get any traction with the idea.

I've been using nvim-gdb for quite some time for it's launch simplicity and proper lldb/gdb/pdb/bashdb command prompt integration. But there's definitely times I want the much fuller feature set of the DAP.

Have you considered this idea any further? I implemented a simplistic proof-of-concept that I have on the VSCode plugin store.. Here is a demo video. IIRC, this works via, in vim terms, calling vs | term lldb-vscode and having a shim layer intercepting the client packets and appending a supportsCommandLine flag. I also added a local change (though upstreamable if it was ever standardized. I have approval of the ideas from lldb's side) that checks for this packet and it will only display the command prompt if asked.

Not directly related but relevant is the mark command in the video. A second proposal idea would be to have the dap-server launch without a target or even a target configuration. Instead the server would just open it's command prompt and function as a command line debugger usually would. file a.out, b main, r would save you from having to create a .vimspector.json at all. (The mark shown in the video clip is just a hack that I used to avoid having to implement the didLaunchTarget lldb listener and packet forwarding to the client.)

@puremourning
Copy link
Owner

I'm not entirely sure what feature of DAP this is requesting, but AFACT the discussion on the 'evaluate'/'console' features in DAP has not progressed. Vimspector has #52 which is the "catch all" for "improvements" to the console window.

and having a shim layer intercepting the client packets and appending a supportsCommandLine flag

what does this mean ? are you saying that there's an interface in vscode-lldb which supports using stdio for user-interactive and opening a port for DAP ? or is that only in your fork of vscode-lldb ?

One thing I considered (and am perhaps open to) is this style where vimspector launches the debug 'adapter' in an interactive terminal window, then speak DAP to it over a socket. We already do that socket communication for CodeLLDB and python remote debugging. There would be UI complexity on the vimspector side, but I think it's manageable.

But as I said before, I'm just 1 person in my (very limited) free time, so anything that requires significant work or ongoing maintenance for niche or uncommon use cases is quite hard for me to justify spending a lot of time on. I would prefer that whatever is done is pioneered through DAP, as any divergence is potential baggage for me in the future.

vs | term lldb-vscode

I think you mean :vertical terminal ;)

@puremourning puremourning added enhancement New feature or request Blocked Needs more information, can't be supported in DAP, etc. labels Feb 25, 2021
@lanza lanza closed this as completed Oct 10, 2021
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Dec 10, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Blocked Needs more information, can't be supported in DAP, etc. enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants