Oni: possibility of visual debugger like vscode

Created on 12 Dec 2016  路  4Comments  路  Source: onivim/oni

One of the killer features that I have seen many developers talk about vscode is its debugger. Is there any plans to implement such debugger in oni. and may be possible integration with react dev tools.

bounty bounty-100 enhancement question

Most helpful comment

With debugging it seems that we can quickly fall in "the matrix" problem (Developing support for each debugger), for debugger there is not a big protocol like LSP :cry:.

VSCode tried to solve this problem with a debugging protocol https://code.visualstudio.com/docs/extensionAPI/api-debugging and debug adapters, but they also proposed an API to write integration without using this protocol. Sadly for us the second option seems used by a lot of extensions and those that are using adapters, the adapters are part of the extension

Example of adapters:
https://github.com/Microsoft/vscode-chrome-debug
https://github.com/Microsoft/vscode-debugadapter-node
(There is a list here not all are debug adapters)

I looked briefly at the protocol this morning and it's seems not complete as the LSP protocol so it can be a reason why it is not so used by vscode extension developers.

I think the best solution here, is to try to use the protocol defined by vscode and if something is missing add some extensions to it (And to propose theses extensions to vscode's team) and to open issues on repositories where the debug adapter is not packaged as a independent binary to see if they can extract it (Or extract it ourselves like for the vscode langservers)

What do you think @bryphe ?

I you think it's a good way to do it, I will try to do a PoC this weekend about integrating the vscode debug protocol in Oni

All 4 comments

Definitely! It's on the roadmap, but hasn't been thought through yet. No IDE would be complete without debugging support :)

Likely this will come after some of the other rich language integration features like completion, but is definitely something we want. My vision for this would be not just stopping at VSCode-level debugging, but to bring in some ideas from IDEs like LightTable as well.

Let me know if you have any ideas or thoughts-

With debugging it seems that we can quickly fall in "the matrix" problem (Developing support for each debugger), for debugger there is not a big protocol like LSP :cry:.

VSCode tried to solve this problem with a debugging protocol https://code.visualstudio.com/docs/extensionAPI/api-debugging and debug adapters, but they also proposed an API to write integration without using this protocol. Sadly for us the second option seems used by a lot of extensions and those that are using adapters, the adapters are part of the extension

Example of adapters:
https://github.com/Microsoft/vscode-chrome-debug
https://github.com/Microsoft/vscode-debugadapter-node
(There is a list here not all are debug adapters)

I looked briefly at the protocol this morning and it's seems not complete as the LSP protocol so it can be a reason why it is not so used by vscode extension developers.

I think the best solution here, is to try to use the protocol defined by vscode and if something is missing add some extensions to it (And to propose theses extensions to vscode's team) and to open issues on repositories where the debug adapter is not packaged as a independent binary to see if they can extract it (Or extract it ourselves like for the vscode langservers)

What do you think @bryphe ?

I you think it's a good way to do it, I will try to do a PoC this weekend about integrating the vscode debug protocol in Oni

Great investigation & summary @DeltaEvo !

Sadly for us the second option seems used by a lot of extensions and those that are using adapters, the adapters are part of the extension

That's a bummer... hopefully the debugging protocol will mature and it will become standardized, so we get something like what we have with the language server ecosystem (and the array of editors that leverage it now).

I think the best solution here, is to try to use the protocol defined by vscode and if something is missing add some extensions to it (And to propose theses extensions to vscode's team) and to open issues on repositories where the debug adapter is not packaged as a independent binary to see if they can extract it (Or extract it ourselves like for the vscode langservers)

I think this sounds like a great plan! It makes sense to start with the protocol... because conceivably it is more general than just VSCode. Seems like a good place for us to start - and by having an implementation that lives outside VSCode, perhaps it could jump-start the ecosystem too.

I you think it's a good way to do it, I will try to do a PoC this weekend about integrating the vscode debug protocol in Oni

That sounds amazing! I can't wait to have a debugger experience that I can navigate vim-style, and swiftly set breakpoints, watches, navigate callstacks, etc without touching a mouse 馃槃

Integrating with this 'mock-debug' adapter might be a good starting point: https://github.com/Microsoft/vscode-mock-debug as that can verify we are listening to the 'protocol' correctly and that our client is listening - it seems like it exercises quite a bit of functionality.

This would be really awesome - keep me posted & let me know if there is anything I can do to help, @DeltaEvo !

To add some extra info here, it looks like MS is stepping up how official and defined the protocol is : https://code.visualstudio.com/blogs/2018/08/07/debug-adapter-protocol-website/#

This includes more indepth docs: https://microsoft.github.io/debug-adapter-protocol/specification
And more examples: https://microsoft.github.io/debug-adapter-protocol/implementors/adapters/

The most exciting part (for me) is the clarification that yes, this is supposed to be for every editor, whereas before it felt like it was a part of VSCode.

This move should emphasize that the Debug Adapter Protocol in not specific to Visual Studio Code. For example, Visual Studio is now also supporting this protocol.

Was this page helpful?
0 / 5 - 0 ratings