[Feature Request] Add Debugger functionality

[kstehn]

I think the title itself says it all.

So i just want to list somethings i found out that might make it easier for someone to tackle this.

First the easy part (VSCode):
Here is the documentation for a debugger extension: https://code.visualstudio.com/api/extension-guides/debugger-extension

I think calva should be able to implement the Debug Adapter protocol.
I guess we can have a look at this code how to actually do it: https://github.com/indiejames/vscode-clojure-debug/blob/master/src/clojureDebug.ts

The harder part is the nrepl side (only when not everything is included in clojureDebug):
For that part i only found the cider-nrepl/debug.clj source code: https://github.com/clojure-emacs/cider-nrepl/blob/master/src/cider/nrepl/middleware/debug.clj

Sadly i didnt find any documentation how the messages should look like.
Maybe we can find this out with the clojureDebug.ts or based on the emacs implementation (here).

[PEZ]

Very good that you bring this up and provide a starting point for collecting information about how to proceed with this.

I have since I started with Calva always thought I should port the VSCode Clojure Debug code over. Do we know if the cider-nrepl debug can be used with ClojureScript?

There is also a another, probably more tricky, way: Using the Java Debugger extension. It would be more like Cursive does it. This would be totally Clojure specific, of course, but that might be compensated by that ClojureScript debugging might become quite easy to achieve through...

... the JavaScript debugger. This almost works already today. But there has been something lacking with the source maps. I read something the other day that this might have been improved in later shadow-cljs versions. We should experiment with that some.

[stefan-toubia]

This is also at the top of my wish list! This would be a very powerful feature to get working, coming from .NET I feel very limited without it.

[elldritch]

Being able to step through an expression as it evaluates would be a gamechanger for me - right now I'm printlning intermediate values.

[bpringe]

Thanks @kstehn for providing that info. I've reviewed it all as well as many other things to wrap my head around debugging in Clojure in general and debugging as it relates to vs code. There are two ultimate goals for debugging - trace and step. I've outlined my notes / thoughts below.

For trace debugging:

• We can use tools.trace to provide trace debugging probably pretty easily (compared to step debugging)
• We can provide a command that prompts a user for a var or namespace to trace - and corresponding untrace commands.
• We could highlight what vars are being traced.
• Basically, parity with cider's tracing: https://docs.cider.mx/cider/debugging/tracing.html

For step debugging:

• We need to write a debug adapter for clojure that would fit in this list: https://microsoft.github.io/debug-adapter-protocol/implementors/adapters/
• It would be easiest and probably best to write it in typescript and utilize the libraries here: https://github.com/Microsoft/vscode-debugadapter-node (as Kevin stated, clojureDebug may help us here)
• If we want expression-based debugging like in cider, I think we can utilize cider-nrepl's debug middleware, but that will be something to figure out.
• If we implement expression-based debugging, do vs code's breakpoints have any role? We can't put a breakpoint in the middle of nested forms on the same line, and I think using the editor's breakpoints implies line-based debugging when it's really not, which may or may not cause problems. We could perhaps support the editor's breakpoints as well as reader macros.
• Even if we don't use the editor's breakpoints, we could still use some other aspects of the provided vs code UI to show things like local and global bindings, a means to change values while execution is paused in a given context (though for this, also being able to explore/modify bindings in the repl would be nice), etc.

I'll be working on likely both of these things over the next few months - step debugging being the more in-demand feature it seems. If anyone has insights they'd like to share I'm always all ears. The real work in all this seems to be wiring up all the pieces, and making it work well with vs code.

[kstehn]

Sounds reasonable.
I would like to point out for the tracing there exist also a Feature request #445
There i also wrote some stuff