You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.)
The text was updated successfully, but these errors were encountered:
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.
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 asupportsCommandLine
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. (Themark
shown in the video clip is just a hack that I used to avoid having to implement thedidLaunchTarget
lldb listener and packet forwarding to the client.)The text was updated successfully, but these errors were encountered: