clojure-lsp works quite hard while it starts, but after that it should be pretty calm...

and it caches for next runs, unless you change your deps file

Can you try with v2.0.235 (the previous version)? I know we did something with the history in 236.

will do that now

v.2.0.235 fixed it

I see... Can you have a look at this, @U02EMBDU2JU? Or whoever of us gets to it first. But I can't until tonight Swedish time (and it is morning now 😃).

https://github.com/BetterThanTomorrow/calva/issues/1504

Thanks!

I'll have a look

Found it. I broke it while refactoring… I’ll post a PR in a bit

Can you elaborate? ”some” is a tad vague 😃

yea sorry, a command like slurp and barf forward backward etc works just fine, but rewrap isnt working and so are other commands. its random. ill try an earlier version of calva first

I doubt 235 fixed this too, but I am curious!

Yes it did, fixed atleast the ones I tried to use and the ones I use frequently

Cant get this one to work tho, but hadnt tried it before I noticed other ones didnt work either. (its set to ctrl+alt+c n by default btw. To sync the Output/REPL window namespace with the current file before switching, use the *Switch Namespace of the Output/REPL Window to Current Namespace* command, ctrl+alt+c alt+n.

Tried it now. That command seems to not work at all. Please report as an issue.

Will do

Please also report the two other issues (history and keyboard shortcuts).. Mention that it works in 235. It'll make it easier for others to choose what to do.

separate issues?

Yes, it makes it easier to discover and also if some issue is harder to kill than some other it gives flexibility in releasing.

Also is extra satisfying if we manage to smash several bugs quickly. 😃

https://github.com/BetterThanTomorrow/calva/issues/1503 https://github.com/BetterThanTomorrow/calva/issues/1505

Totally appreciate that you took your time to help me with this, @U02CX2V8PJN!

Sure no problem, loving Calva! 🙂

@U02CX2V8PJN I can’t reproduce rewrap not working @U0ETXRFEW can you?

Actually I can't...

Ill have a look when I have time this afternoon

To see if I can reproduce (again)

thank you

didnt have time yet, ill try tomorrow

I'm thinking we should add this to the end-to-end setup we have (badly? named integration-tests) where we currently only check that the extension starts.

might be calva’s pretty printer? do you have a non default one set?

Dont think so. Just tried turning pprint off and it gives me the output without stackoverflowerror

This is the when expression: { "key": "ctrl+alt+c p", "command": "calva.togglePrettyPrint", "when": "calva:connected && calva:keybindingsEnabled && editorLangId == 'clojure'" }

right, could be an issue with the atom

heres the doc for custom pretty printing i mean: https://calva.io/pprint/

When I do this the repl output prints about 5000+ lines :rolling_on_the_floor_laughing: (clojure.pprint/pprint @(:jobs-ref @(:pool-atom scheduler/scheduler)))

Infinite recursion

nice

"calva.prettyPrintingOptions": {
    
        "enabled": true,
        "width": 80,
        "maxLength": 100,
        "printEngine": "calva"
    },

trying now

Works now with pprint enabled and your settings. Gives a plain printing response. ; Plain printing, b/c pprint failed. (Invalid symbol: id:.)

much better then just a stackoverflowerror

Thanks!

You're welcome!

Saves me opening a terminal to connect to the repl :rolling_on_the_floor_laughing: and switching windows 😶

btw if you could create a ticket with a small repro snippet we might be able to fix this for the default printer

We should consider making calva the default pretty printer.

I’d also like zprint to be the default server printer, but I think we would have to harden the deps injection before we do that, or manage to fail back into pprint when zprint is missing

And (for someone having the time in some future) since that is client side zprint, we would open up possibilities for us to let people use whatever zprint config they fancy. zprint is pretty configurable. 😃

ill create an issue

There is actually code in Calva (or maybe in some branch) that injects zprint dependencies. But I think we would need to go for side-loading if we really want to ensure it.

very much not on topic: I always had problems finding enough stuff to work on, now I have the exact opposite problem 🙂

That's what Calva does for ya!

the zprint is already being injected in the main branch, but it’s hard to communicate that you can’t just change the setting but also need to restart repl and so on

> That’s what Calva does for ya! It’s omni-trace for me. Because of it I’ve worked on calva, orchard, oz, portal, clojure-lsp and soon clj-kondo 🙂

I can relate!

Purposely crashed my VSCode for you to create an issue with reproduction steps lol. https://github.com/BetterThanTomorrow/calva/issues/1506

Unfortunately there isn't. We should fix this. Currently we track it in this issue: https://github.com/BetterThanTomorrow/calva/issues/1254

Ok, great to know!

I would also would like to configure the jackin question to remember my choice of babashla/deps/lein etc. Maybe the same solution could work for both problems?

Please elaborate a bit on that idea. 😃

I'm asking because currently jack-in does remember this choice, but obviously not in a way that you would like.

Aha 🙂 I think it does pre-select the last alternative, but I would like it to skip the question.

A “Remember my choice and don’t ask again” kind of thing

I think you can get that with a custom connect sequence, but I’ve been to lazy to write them for my projects 🙂

Not for the project type, I think, @U02EMBDU2JU. The sequence will place itself as a project type. 😃

ah ok. then it makes even more sense to have an option to skip all that. so many things to build! 🙂

I usually say no to options. Less to build. 😃

For this one I think I want to build it. I even have it in some branch like that. Because Calva used to just skip the question if there was a connect sequence there, and when I removed that behaviour I also had a branch where I made it optional. Don't remember why I choose to skip it. Probably because ”if I build less, I have less to maintain”.

I would actually like to configure it in something that is checked in. That is, I would like to be able to tell my coworkers to clone a project and jack-in, without having them confused by additional questions.

But as with any such magic, it can be hard to understand where to change it later, so I understand the current decisision to ask every time.

We could consider a command like ”Jack-in like last time” (not finished copy).

Hmm, that might be a #clojure thing? throw is a special form. It seems like clj-kondo knows about this and does not warn about the redefinition (because that is not happening).

Right. Throw is a special form

And also you can't redefine Clojure core functions because they are compiled. Can't remember the exact term

I can under special form is a different case.

But for functions, they shall be able to be redefined though. While AOT might come into play in this case.

I was thinking about direct linking https://clojure.org/guides/faq#direct_linking_repl

direct linking doesn't prevent redefinition

new code compiled after redefinition will see changes, just anything already compiled with direct linking won't see them. so if you change +, that's fine - new code will see your redefinition, but code inside clojure core will not (as it's AOT compiled with direct linking)

Good to learn this. Is direct linking enabled for all compiled code regardless being in clojure.core or not ?

Maybe clojure-lsp semantic tokens should treat special forms special, @UKFSJSM38?

@UGC0NEP4Y no, direct linking is off by default

what do you mean @U0ETXRFEW? you mean color throw as a macro?

we rely on kondo analysis for semantic tokens, for this one clj-kondo tells that throw is a var-usage just like others, it doesn't add the :macro true to the analysis which would make us coloring differently

@UGC0NEP4Y direct linking is really intended to be used "at the end" when you compile an application into an uber jar or something - you'll get smaller compiled code, faster load times, and faster execution (but you lose some dynamicity). Clojure core is kind of a special case because it's always "at the bottom".

@UKFSJSM38 That's how it is colored the jiffy just before the semantic tokens get hold of it. 😃 Goes for if and some other forms as well. Probably kondo should say :special-form: true for this one. It's what cider-nrepl says. And it adds :macro true for those special forms that are also macros.

yes, makes sense to me, WDYT @U04V15CAJ?

sorry, what?

I like that direct linking is off by default. Just blurting that out. 😃

@U04V15CAJ the special forms get colored as functions by clojure-lsp. Kondo can help by informing about the specialness.

yeah, it could add that to the analysis output

kondo already does that for if/when because they are macros, but not for throw

@UGC0NEP4Y interestingly some things are not direct linked in clojure core, like conj. ran into this here: https://github.com/clojure-emacs/orchard/pull/147

throw is not a macro but a special form

yes, the point is that clj-kondo could send a info saying that is a special form

so clojure-lsp can color like macros or other color users would choose

issue welcome

if is also a special form. And looks like a regular function in Calva.

yeah, I can repro that as well :thinking_face:

@U02EMBDU2JU conj is direct linked, so that doesn't make sense to me (you won't see direct linking when a function is used as a HOF though)

oh, the example there is reverse, which indeed is using conj as a HOF. something like select-keys is an example where direct linking would happen

@U064X3EF3 ah you are right, I miss remembered. sorry for spreading missinformation

Everything in Clojure that is pre compiled (which is almost everything, but not quite), and that is not marked as ^:dynamic or ^:redef will be direct linked

My deps.edn for this project (that used to work).

{:paths ["src" "resources"]
 :deps {org.clojure/clojure {:mvn/version "1.10.1"}
        vlaaad/remote-repl {:mvn/version "1.1"}}
 :aliases
 {
  :remote-repl {:extra-deps {vlaaad/remote-repl {:mvn/version "1.1"}}}
  :reveal {:extra-deps {vlaaad/reveal {:mvn/version "1.0.130"}}}
  :test {:extra-paths ["test"]
         :extra-deps {org.clojure/test.check {:mvn/version "1.0.0"}}}
  :runner
  {:extra-deps {com.cognitect/test-runner
                {:git/url ""
                 :sha "b6b3193fcc42659d7e46ecd1884a228993441182"}}
   :main-opts ["-m" "cognitect.test-runner"
               "-d" "test"]}
  :uberjar {:extra-deps {seancorfield/depstar {:mvn/version "1.1.128"}}
            :main-opts ["-m" "hf.depstar.uberjar" "maze-solver.jar"
                        "-C" "-m" "exfn.maze-solver"]}}}

Tried a few other projects that I also knew worked (e.g. this years advent of code project) and I'm getting same error.

My clojure is 1.10.1 I can create a repl via the command line

(base) [18:32]: [email protected]:~$ clj
Clojure 1.10.1
user=> (+ 1 1)
2
user=> 

Stripped the deps.edn down to just

{:paths ["src" "resources"]
 :deps {org.clojure/clojure {:mvn/version "1.10.1"}}
 }

We have recently changed code around this. Maybe we broke something. Are you selecting any aliases?

I'm not.

I can start the "Getting Started" repl

What I see

went back to v2.0.225 and it works

I'll find the version where it stops working

2.0.231 works 2.0.232 doesnt work. I can't jack in with this version onward

Any debug / logs or anything I can give you to help ?

I’m afk. What does the changelog for 232 say?

https://github.com/BetterThanTomorrow/calva/releases/tag/v2.0.232 • https://github.com/BetterThanTomorrow/calva/issues/1355 • Fix: https://github.com/BetterThanTomorrow/calva/issues/1386 • Fix: https://github.com/BetterThanTomorrow/calva/issues/1448

Ok, the problem was at my end. I was on CLojure 1.10.1, I upgraded to 1.10.3 and now it all works.

So maybe the change in 2.0.232 to add the -M isn't supported in 1.10.1

I see. Now I feel a bit slow. 😃 But now I get it, at least. Indeed, we were a bit too quick to make that change. In 235 we added an option to stay with -A, for people working in projects that haven't upgraded.

Don't confuse Clojure versions with CLI versions.

Check what clojure -version says -- I expect you upgraded the CLI @U013YN3T4DA to fix this? Because your CLI version was too old.

The version of Clojure (the language) is independent of the version of the CLI (the command-line tool). The latter just happens to specify a default version of Clojure if your deps.edn doesn't do so explicitly (which I would always strongly recommend doing). You can run any version of Clojure with any version of the CLI (since they are independent).