I think we need a way to get access to main debugger features for a given program. I know the ghci debbuger but it would be nice if it could be run by a public API
An API wich provides:
You can have a good overview of IDE needs by looking at the VSCode debuging protocol:
https://github.com/Microsoft/vscode-debugadapter-node/blob/master/protocol/src/debugProtocol.ts
With more general explanation here:
https://code.visualstudio.com/docs/extensionAPI/api-debugging
ide-backend's debugger support never got very sophisticated, but it may be helpful to reference https://github.com/fpco/ide-backend/blob/master/ide-backend-server/Run.hs#L413
I've actually been looking at the vscode/omnisharp protocol again, with a view to building a HIE transport for it. Which brings in all the omnisharp-capable IDEs at one fell swoop.
Phoityne meets most some of above requirements
https://hackage.haskell.org/package/phoityne-vscode
https://marketplace.visualstudio.com/items?itemName=phoityne.phoityne-vscode

edit:
from readme:
supportsConfigurationDoneRequest : yes
supportsFunctionBreakpoints : yes
supportsConditionalBreakpoints : yes
supportsEvaluateForHovers : yes
exceptionBreakpointFilters : no
supportsStepBack : no
supportsSetVariable : no
supportsRestartFrame : no
supportsGotoTargetsRequest : no
supportsStepInTargetsRequest : no
supportsCompletionsRequest : yes
Some information from LSP4E (Eclipse LSP Client project): https://github.com/eclipse/lsp4j/issues/130
The Phoityne debugger uses this at the back https://hackage.haskell.org/package/haskell-dap which implements the vscode debug protocal, as I understand it.
Using a standard protocol makes sense to me, but it is not as widely implemented as LSP. See https://code.visualstudio.com/docs/extensionAPI/api-debugging
And there is a ticket asking for LSP4J support, it is a complex ecosystem.
Any update on this?
more useful links:
The standard is now DAP, I would say, supported in both emacs and vscode.
And as I said earlier, phoityne already supports it, maybe we should consider an integration with it.
Fundamentally this is about having a GHCI session at the same time, which has been considered quite a bit. See e.g https://gitlab.haskell.org/ghc/ghc/issues/15461
Most helpful comment
I've actually been looking at the vscode/omnisharp protocol again, with a view to building a HIE transport for it. Which brings in all the omnisharp-capable IDEs at one fell swoop.