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
move debug adapter protocol to separate repository #19636
Comments
Any progress here? |
It'd be great to see some work towards standardizing the vscode debug protocol following the success of the LSP (see also https://github.com/Microsoft/vscode-debugadapter-node/issues/59), and this would be a good first step. Getting other IDEs to implement the vscode debug protocol would be especially useful now that the Java Debug Server has been released. |
Is the fact that the debug protocol lives in https://github.com/Microsoft/vscode-debugadapter-node blocking anyone from adopting it? |
@weinand I think debug protocol feels more like an internal vscode thing than LSP. It starts with the name of the repositories, LSP lives on language-server-protocol vs the vscode-debugadapter-node which is prefixed vscode. README file for the debug things repo also does help either. It only talks about VS Code and has no information around contribution. I love the fact that there is a json schema for debug protocol but there is no information on the repository that schema is the source of truth for the protocol. At the moment, it is even a bigger leap of faith (yeah, I think LSP needs open governance) for Eclipse Che, Atom or any other editor to adopt debug protocol. And because it feels like an internal implementation so far Red Hat could not really consider it for adoption. |
This feature has great potential. I believe that with more documentation and some in-house guides on how to create adapters for other editors (starting with Atom maybe?) this would be a step in the right direction. |
@CestDiego The idea behind debug adapters is to be independent from a debugger frontend so that they can be reused across different IDEs. So "creating adapters" for Atom doesn't make any sense. The better approach would be to host debug adapters in Atom. |
The DAP now lives here: https://microsoft.github.io/debug-adapter-protocol/ |
move debug adapter protocol schema and accompanying documentation (Readme.md) to a separate repository.
The text was updated successfully, but these errors were encountered: