I love that slack feature, it's the only way I know wherever one mention LSP in any channel 😅 Almost sure borkdude does the same for clj-kondo and bb 😛

Would borkdude use such easy means? 😃

It's funny how when all three, Calva, clj-kondo, and clojure-lsp are mentioned, we all three pop in: ”You summoned us?”

We've recently changed some around the pretty print defaults. Maybe that causes the new behaviour for you. See if you have any settings configured. And see if this page helps any to get it behave like you want: https://calva.io/pprint/ Basically, Calva just dispatches this work to the pretty print engine you choose, and they all behave a bit differently with the options.

Thank you, I'll play around with it

I experimented a littlebit. I (tried to) start a fresh vscode without settings by pointing it to an empty directory with

code --user-settings-dir vscode --sync off .

When I use clojure.pprint directly, it does wrap, but at column 1024

Ah, babashka... So Calva should do some checks, that it doesn't do on the nrepl server. I don't think babashka's nrepl server implements the pretty printing op.

aha, interesting, I didn't realise there was a diffreence. I'll try with normal clojure

You should be able to use the calva pretty print engine. Just know that if you produce infinite results, then maxLength won't save you, as it does with server side printers.

Calva assumes cider-nrepl which isn't true for babashka.

Using the calva engine gives me the desired results, both for regular clojure and babashka

It also turns out that even with --user-settings-dir, vscode still picked up some old settings. Do you have good way to create clean repro-cases with vscode?

The calva engine operates client side and does not rely on any nrepl op being in place for it. It will however, hang if you evaluate an infinite sequence. Something that can be avoided by setting maxLength with the server side options. You can interrupt the evaluation if that happens.

For settings I just make sure that I'm using the settings I want to test. Commenting out any settings I use outside testing. My settings file are a mess, actually.

Thank you for your help!

#_#_

in this particular case a line comment (`;` or ;;) should also work. I think paredit-enabled editors are generally able to detect what you mean and move the closing curly brace to a new line automatically. edit: oops, sorry, I didn't realize we're in #calva . Not sure if that works as I described

right. Calva has parinfer mode to get the closing parens right.

> paredit-enabled I am not sure the normal structure-editing provided by paredit has such capability?

It does seem that Calva doesn't work like that 🙂 I'm pretty sure that's how paredit-mode works out of the box on emacs, so it's generally what I've come to expect when I use paredit. I thought Calva and Cursive also did it like that but I was obviously wrong about Calva and I haven't used Cursive in years so my memory must be failing me. #_#_ is perfectly fine 🙂

God the more i learn about parinfer the more I want it

There is no such option. But generally Calva tries to reconnect in such situations I think...

When I use Generic repl connection from a non project folder, it is closing connection.

Do I need cider or Cider.nrepl Middleware as deps ?

Not to keep the connection. That sounds like something is wron. But generally Calva assumes cider-nrepl to function fully.

The correct option might be to look for .nrepl.edn file

Calva doesn't recognise the .nrepl-port file I placed in the project root. I hard coded the port to 22222. Is it because it first looks for project.clj or deps.edn folder?

I think that with Generic it doesn't look for the port file. Maybe it should...

I don't think we have ever made something special inside strings. It should basically move by word inside strings and jump over strings if outside them. Sounds weird that it should move to beginning/end inside strings. Can you provide an example?

Interesting, you’re right. I’m noticing that it behaves the way I’d expect with a string like “foo bar”, but not with a string like “foo/bar”. Normally alt+right/left stops at word separators (as defined by the editor.wordSeparators setting), but inside strings it seems like Calva only stops at spaces.

Yes, it is still moving by sexpressions inside strings. The wordSeparators setting is not involved. If there is a when clause context for within string you might get away with adding that (negated) to the shortcut binding.

Thanks for the tip, this ended up working:

{
    "key": "alt+right",
    "command": "cursorWordEndRight",
    "when": "calva:cursorInString && calva:keybindingsEnabled && editorTextFocus && editorLangId == 'clojure' && paredit:keyMap =~ /original|strict/"
},
{
    "key": "alt+left",
    "command": "cursorWordLeft",
    "when": "calva:cursorInString && calva:keybindingsEnabled && editorTextFocus && editorLangId == 'clojure' && paredit:keyMap =~ /original|strict/"
},

Not sure if this convo has been moved to GH, but pinging @U0ETXRFEW here just in case.

Oh, I’ve forgotten to reply. Thanks, @U9A1RLFNV ! I’m undecided about making this the Calva default. Maybe users who want this rather should either do it themselves, or consider this (from the docs): > You can relax how Paredit's shortcuts replace VS Code built in shortcuts a bit by setting calva.paredit.hijackVSCodeDefaults to false.

There is one more thing complicating this. We are removing these contexts in the multi cursor branch. Out at least that's how it looks now. @U037TPXKBGS has been looking at it some and it gets complicated to keep them when cursors can be in different contexts…

Yes, I agree both that default behavior might vary across users. However, I also agree that making it possible for users to configure is tricky with multi cursors! Any ideas would be appreciated heavily! A dirty option might be to keep the contexts but they only apply to the primary cursor. 🤷:skin-tone-4:

My first thought is that Calva should probably do the same thing VSCode does in these situations, so I took a look through the default VSCode contexts. Unfortunately none of them have the same problem we’re talking about here, so no luck there. My next thought is that as a user, I’d expect each cursor to behave independently, so cursors inside strings and cursors outside strings would be sent different commands. I’m not sure that’s possible though. My final thought is that I notice that the default VSCode contexts seem to deal with multiple selection by providing multiple contexts: see editorHasSelection/editorHasMultipleSelections, etc. One solution would be to provide multiple contexts: anyCursorInString, allCursorsInString, maybe also oneCursorInString?

This is the same person and question as here. https://clojurians.slack.com/archives/C053AK3F9/p1649737136121179 Just noting.

I haven't used Figwheel Main in a while. I think I should do that to see that things still work from a Calva perspective.

OK. Now tested both the tools-deps and lein templates. Things work. Now will try to formulate some kind of help there...

👍:skin-tone-4: