search

palantir / python-language-server

An implementation of the Language Server Protocol for Python
MIT License
2.6k stars 283 forks source link

Consider supporting an LSP debug extension #221

Open gatesn opened 6 years ago

gatesn commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

According to https://github.com/atom/atom/issues/9841#issuecomment-345393394 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 https://github.com/facebook-atom/atom-ide-ui/issues/75#issuecomment-336261833 it most likely will be the VSCode debug extension API ;)

jamding commented 6 years ago

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