My pet peeve was lack of multi cursor paredit command support, but that’s now getting better! 🎉

@javierweiss I see what you refer to now. We could probably present compound values for easier consumption in the debug pane. What I do is that I evaluate the things I am interested in. Portal not needed for that. But Portal is of course to prefer if the values are any deep and I need to traverse. But that goes for any evaluation, not just the ones from a debugger frame.

@U04V70XH6 I wish I had the slightest clue what causes that hang. It’s very strange.

The 2 biggest frictions are (1) comments. Emacs aligned ;; comments with the code, but Calva leaves ;; comments where they stand, so, as I work with code and add or remove layers the ;; comments are in goofy places. And (2) focus fallback, which sometimes manifests as handling keystrokes out-of-order (call me crazy, but I'm sure of it). Especially in large-ish (> 500 line) files. The most common case is the spacebar, but it's also the one where everyone might wonder if I'm imagining things. The next-most egregious example, the one that makes me think I might not be imagining things, is ctrl-f to find. I'll be busily typing stuff, without a pause I'll impatiently hit ctrl-f and type elephant, then I'll notice only ele on the Find blank, and phant got typed into my clj file. We should never speculate about the origin of these problems! But, just for fun, I speculate that in JS everything is async; probably a lot of keystrokes start an async consultation of LSP or something. The answer arrives later, possibly "much later" relative to the timeline of other keys I may have pressed. But VSCode performs the answer anyway, yanking focus back to where it used to be.

I wonder if Calva could be moving the focus… I don’t think I recall such a thing, but that doesn’t say much about wether the thing exists or not.

Thanks!

Does it seem like I have understood the problem correctly?

I almost never use the debugger myself, so it is a bit of a blind spot for me.

Yes! If I'm able to document other issues I'll let you know.

> Sometimes it hangs when looping, unfortunately cannot tell under what specific circumstances... Could it be infinite sequences that trips it up? https://calva.io/debugger/#debugger-hangs-when-stepping-over-infinite-seqs

Not that I remember. I don't know if the environment might have something to do. I usually work with WSL2 on Windows 10 with Ubuntu 22.04 and sometimes on Windows 10.

Well, we have at least one more hang mentioned in this thread that seems to happen only with WSL. ¯\(ツ)/¯

A couple of times recently I've had both Calva and Cider simultaneously connected to the same REPL, and found the confusing behaviour where evaluating a #dbg / #break from within Emacs causes Calva's debugger to take over control

Cool.

Not sure how supported a use case that is, multiple nREPL connections from different editors - though it's just a small friction of disconnecting Calva once I realise what's going on, so I haven't really looked into it - probably a faulty assumptions on cider-nrepl side of things

Please report as an issue, @UCPS050BV. I doubt I can fix it, but we can investigate it a bit and worst case is that we close the issue with an update to the docs.

alright, once I get round to a proper repro - feels warranted for opening an actual github issue

I do find some of the default keybinding choices quite clunky - particularly the Ctrl-alt-C prefix, which it seems like VSCode doesn't provide a way of remapping en-masse

I don’t think it the CIDER/Calva debugging clash needs a proper repro. What you described there is enough for now.

Keybindings are bound (sorry) to be subjectively clunky whatever we do. So they are entirely on the user side of things to remap. Even if crowdsourcing it is probably a good idea for the en-masse rebinding case. If such a repository is created I’d be most happy to promote it in the Calva docs.

Yeah, maybe that's just Emacs-centric bias where "chorded" bindings are just prefix keys bound to a nested keymap, so I can just directly map my desired alt-C prefix to whatever ctrl-alt-c was originally. Not sure if that's something a vscode extension is allowed to do? Expose some "prefix key" option in preferences and dynamically create bindings

Oh, the one that stuck out especially was "Raise Sexp" bound to ctrl-alt-P ctrl-alt-R , given how it's one of the most useful paredit commands

VS Code extensions can update state that is accessible from when clauses in keybindings. (Calva does quite a bit of this.) I think that could used for implementing a prefix thing. You could use #C03DPCLCV9N to experiment with it. And possibly the solution as such can stay as a Joyride script for people to use, but depending on the outcome of the experiment it could be considered for Calva to implement.

@javierweiss (and anyone else caring about the debugger): https://clojurians.slack.com/archives/CBE668G4R/p1712322207087589

@U0ETXRFEW The #2 item @U0HG4EHMH mentioned has also happened to me. Sometimes it happens just in an editor, while typing fast, that some combination of auto-close parens or auto-complete in general seems to get out of sync with typing and the cursor jumps to a different place on the line halfway through, resulting in somewhat garbled code (because what I typed ends up appearing out of order). As for the hangs, it is nearly always on a backspace, but it does happen occasionally at other times. I think it is nearly always when some action triggers an extension to do something -- I sometimes see "Activating extensions..." appear in the status bar on a Calva-related key stroke (even when VS Code has been open for ages and all the extensions are activated/running). I think running GitLens may also contribute to the hangs since that puts a git blame annotation on the line the cursor is on and sometimes that seems to lag too...

Re-indentation does not always work, especially for incomplete expressions. Sometimes it does, but sometimes it does nothing. That said, I think that it always does work to go through the expression that I am editing from top to bottom, selecting each newline character, and hitting the return key. When I do that, the next line (on which my cursor now sits) is indented correctly. So Calva somehow does know what the re-indentation should be -- it's just that it makes me go through this cumbersome line-by-line process to properly re-indent an expression. It'd be great if it could just do this itself when I ask for re-indentation. As I'm pretty sure I've mentioned enough for people to be sick of it 😕, aside from bracket matching this is the single most important function of a Lisp editor IMO. When I'm working with students I find that most of their errors become obvious once they re-indent, and if re-indentation often doesn't work then they spend a lot more time being confused.

Re-indentation works if the structure is non-broken though, so from my perspective you are partly causing the problems yourself by insisting on not accepting the help of protecting the structure.

Understood, but "accepting the help of protecting the structure" is a non-starter from my perspective. Yes, I understand why it makes sense and why some people love it. But strict editing is terrible for me (and yes, I've given it a serious go several times in my 40 years of Lisping), I guess because I think and code in a somewhat non-linear way, and my fingers and brain want to use the same typing/cutting/pasting skills that I use everywhere else. For my students, maybe they won't be so recalcitrant later but I'm foisting many other new things on them at the same time -- functional programming, immutability, evolutionary computing, etc. -- and if they have to also learn a new way to type at the same time it is terribly discouraging, especially for the students I most want to feel welcomed and empowered. So neither they nor I will be working in a strict editing context.

As for the differences in when Calva manages to re-indent or not: Calva has two mechanisms for re-indenting code. 1. One is using cljfmt, which only deals with complete, non-broken, structures. It re-indents the whole structure it is given. To help it with broken structures, Calva tries to first heal it. If this fails, no re-indentation will happen. 2. A line-by-line indenter. This is all Calva code and uses Calva’s own structural representation of the code, it uses the current cursor position and tries to figure out where the next line should be indented. It’s not really suitable to deal with a whole block of code.

Would it be possible to automate the application of the line-by-line indenter for each line of the file from the top down, rather than starting at the current cursor position? I think that would do exactly what I want.

You could probably write a #C03DPCLCV9N script that does this.

Any way something like this could be made available out of the box, for a student who has just for the first time downloaded VS Code, enabled Calva, and is trying to write their first Clojure code? As you know I think it would also be awesome if such a minimal setup would also allow them create a minimal deps.edn Clojure project (with a deps.edn containing just {} and a src directory with a core.clj with an ns form, which otherwise requires a page or so of tedious instructions). If they could download VS Code, enable Calva, do something in the GUI to make the minimal project, jack in, and begin writing code with bracket matching and re-indentation then we would all be happy as clams.

I have on my todo to make Calva help with creating a minimal Clojure project. Not on my todo: re-indent broken Clojure code beyond what Calva already does for this.

Too much of Calva and of the tooling it uses break in the presens of broken code. All bets are off. So the efforts are put into keeping the code non-broken, and to some extent to try heal broken code.

Understood. Although to be clear, Calva already correctly does what I want with respect to re-indentation except that it makes one manually visit each line and replace each newline with a new one. If that could be automated in a beginner-friendly way (not requiring understanding something new like Joyride) then the job would be done. I just tried to experiment to see if cutting and pasting the whole contents of the file would fix the indentation, but weirdly right now it's properly re-indenting incomplete code when I hit Tab... which it seems to do sometimes, but not other times, and I don't know what makes the difference. I guess it's good that it does it sometimes, but it can't be relied upon and I also can't experiment. FWIW thought it's also doing more than I want because it's pulling closing brackets up to previous lines and doing other reformatting that I don't actually want. I just want the indentation fixed, which again I think that Calva already actually does perfectly iff one manually replaces every newline, one at a time from the top.