Consider supporting an LSP debug extension

[gatesn]

VSCode has a well-defined debugger protocol, if we wrapped this in a debug namespace then it wouldn't be unreasonable to write a thin-wrapper in the VSCode client extension to support debugging in the language server.

The advantage of this is that other editors could then write their own translation layers to this debug protocol. @lgeiger is this something Atom might be able to support?

LSP4J is working on releasing the Java interfaces for the protocol here: https://github.com/eclipse/lsp4j/tree/master/org.eclipse.lsp4j.debug/src/main/java/org/eclipse/lsp4j/debug/services

[lgeiger]

AFAIK Atom currently has no official debugger protocol, though I think https://nuclide.io does something similar.

Since this isn't part of the language server spec, I don't think atom-language will implement this any time soon.

That said I'm sure it's possible to implement something similar for Atom if someone is interested and has time doing it.

[exploide]

According to atom/atom#9841 (comment) Nuclide devs are working with Atom devs to bring Nuclide's debugging functionality to Atom. I would assume this will happen in an extensible way.

Though, it's stated there that Nuclide debugger already supports Python. But I haven't tried this and don't know if this is already awesome or something experimental that could benefit from an improved language-server-python based debugger.

EDIT: and according to facebookarchive/atom-ide-ui#75 (comment) it most likely will be the VSCode debug extension API ;)

[jamding]

Both DAP and LSP have mechanisms for request-response and single-sided event emitting, and for the most part there's pretty obvious mappings from 1 message format to the other, but worth calling out that the debug protocol's "events" have a seq field whereas the LSP's "notifications" do not.

Really simple proposal would be wrapping an event's seq and body as fields in a notification's params field