Maybe related, when I do cider-eval-sexp-up-to-point inside a let, I get errors of unresolved symbols (the ones defined in the lets), as if the let was not evaluated?

Not sure if it helps, but there is also cider-eval-sexp-at-point-in-context where you can specify missing let-bindings interactively

will try it, thx!

What if there's already a deps.edn/etc file? Given those possible ramifications, I'd suggest creating a detailed github issue - it would be most welcome

I'll take a few more notes and open an issue. thx!

This is fine to escalate to a GH issue - the debugger is occasionally but steadily maintained

I’m just so bad with Emacs, I don’t know if I am doing my test wrong. Where should the issue be raised if we deem there should be one raised?

Upon further investigation using Calva, I think I now have reason to suspect the bug is in cider-nrepl. I reported it here: https://github.com/clojure-emacs/cider-nrepl/issues/865

Let me know if I can improve the issue. And let me know if you want me to have a look at how to fix it. Can’t promise success, but I would find it fun to give it a go.

Issue looks great, thank you :) Probably a repro in form of a deftest would be a good start if you'd want to give it a shot - IIRC there are misc tests for the debugger. WIth a bit of luck that failing test would make things easy enough for you to also come up with a fix

Ah, thanks for the pointers!

hi @U0ETXRFEW, I can take a look

Be my guest, @U0739PUFQ. Something that would help me tons is if you record yourself taking a look. It was a long time ago I tried to hack on anything nrepl, and I remember having troubles finding a good setup and workflow.

sure

so both examples (the one on the issue and the one here) works for me

fwiw, cider-nrepl has a decent readme and makefile, if you find it's not the case we'd be happy to keep a hackable env

the debugger is stopping first on (3 1) for !a and then on (3) for (deref !a)

@U0739PUFQ, ah, so we have some cases like that in Calva for syntax quotes and such. I should add one for deref too?

this is how it shows

this is the message that starts the thing (when we evaluate (boom)) it will stop first on (3 1)

I knew I was holding CIDER wrong!

and then, when we ask for :next it will return the value for (3) for the deref

Then we should close the issue. And possibly raise a new one about documentation for the coor thing and what to expect as an implementor.

I can explain how that works

I know the basics of it. It is the “special” cases I don’t know of.

Does the CIDER debugger show the value #atom[0 …] for the [3] path?

so, when you eval instrumented, the debugger is first walking down the expression (before macroexpansion) and tagging all symbols and expressions with a coord meta. So here it will be tagging (deref ...) with (3) and !a with (3 1). Then it macroexpands and then it walks down the macroexpanded form, and when it sees a coor tag it will wrap it with the breaking/reporting

Or the [3 1] path that should be, I guess.

> Does the CIDER debugger show the value #atom[0 …] for the [3] path? the #atom[..] is for [3 1], that is the first screenshot I pasted

[3] will be reported for the deref, so, the integer

which is the second screenshot

Or third. 😃

true haha

Off by one errors. Haha.

yeah XD, was referring to the nrepl messages screenshots

My question is if there’s a corresponding screenshot for the first screenshot (the really first one) where it shows the atom value. Or if it skips that and shows only the value inside.

oh yeah, let me run it again

if you want to try it yourself, what I'm doing here is after jack-in, runing M-x cider-selector then m, this will show you the *nrepl-messages ...* buffer where you can see all the messaging exchanges. On a Clojure buffer you define the function and evaluate it with C-u C-M-x , that will evaluate it wrapped in a #dbg, so no need to write that tag. It will highlight the function when it is instrumented. Then when you run (boom) you should find yourself inside the debugger. Hitting the n key should move you step by step until the end

I had a completely other UI when I tried this. It was some big buttons in the title bar of the window, and when I pressed the one I think corresponds to step over, it crashed with the Java exception in TS.

I get suicidal trying to use Emacs, actually. I wish I had more patience. But if I can figure out how to get the UI you get there, then the nrepl message log would be helpful for me to try to figure out how Calva should deal with this.

sure, let me know if you need help with that, I can jump into a meeting

Can you jump into a meeting now? 😃

sure

Awesome!

dang

I guess we should go with zoom or google meetup

Ah, do you have a pay zoom? Give me a link and I’ll join.

I have normal zoom, I don't pay anything XD

Maybe the curfew is good anyway. I’ll cook a link.

I think this is it https://us04web.zoom.us/j/73216880960?pwd=AkRGpyhOu2WNktE43FqF16RsFKZ07D.1 Zoom is about as easy to use as Emacs is for me. 😃

yeah haha

looks like I'm waiting for you to accept me

I was holding CIDER wrong, and have closed the issue. Will release a fixed Calva in a jiffy. Thanks @U0739PUFQ! However, CIDER invited me to click the wrong button. I didn’t even see the command bar that appeared in the buffer, and instead went for the rather huge green arrow with the tooltip next. Clicking that throws the java error from the thread start.

Feel free to suggest improvements around, whether they're UX or cider-nrepl docs

I use CIDER so seldom, only to ask questions like What would CIDER do?. So not sure I am one to suggest much. But in this case, probably the best fix is to make the big buttons in the toolbar do the corresponding things as the commands in the buffer. I can have a look at it. 😃