I added a comment to the discussion thread now. Mainly relaying that I don't find it being a big problem with Calva written in TypeScript.

Thanks, @U0ETXRFEW! Yes, I think that’s important to emphasize. @U9A1RLFNV and I have also added comments to a similar effect in the discussion, trying to point out that there is little point in rewriting stuff just to rewrite stuff, unless it offers some significant advantages. And if using TypeScript for VS Code is more productive than the benefits one would get from using ClojureScripts (because that is a more idiomatic/supported way of developing VS Code extensions), then it probably does not make sense to change language just for the sake of it, either.

The major wins with ClojureScipt over TypeScript as I see it are: • Reach into the Clojure ecosystem • Hot reload I feel a bit like a cave man reloading the Calva extension when developing. 😃 But, as I've also stated, TypeScript is still nice and keeps me productive.

I’ve added a comment in the thread, but I very much agree with all of @U0ETXRFEWs statements.

Could be a garbled 233 install. If you delete the entry in the extensions folder and install 233 anew, does that work?

Thanks - afraid that didn’t work though

I don’t think there is anything. As far as I understand the formatter tries to avoid adding/removing new lines in code. When I have the problem I run the “Eval current form and replace it with the result” command. This basically does what you want. But I think we should probably add a second command that helps you do that on more than a single form, what do you think @U0ETXRFEW @U9A1RLFNV?

zprint comes to mind. It is much more ”aggressive” than cljfmt. Calva's formatter does not currently support using zprint, but you can run it standalone on a file: https://github.com/kkinnear/zprint/blob/master/doc/using/files.md

Thank you! I wouldn't jedné thought about "dal and replace", will try that.

yeah, thats why I think we should add a second name for it. It actually works great but I’m not sure anyone but me uses it for this purpose. Plus you need to use it on the map, not on the whole def, which makes it harder to use.

[2022-01-14 13:49:45.540 - WARNING] :shadow.cljs.devtools.server.nrepl/middleware-fail - {:sym cider.nrepl/cider-middleware}
Note: The following stack trace applies to the reader or compiler, your code was not executed.
CompilerException Syntax error compiling at (cider/nrepl.clj:1:1). #:clojure.error{:phase :compile-syntax-check, :line 1, :column 1, :source "cider/nrepl.clj"}
        clojure.lang.Compiler.load (Compiler.java:7648)
        clojure.lang.RT.loadResourceScript (RT.java:381)
        clojure.lang.RT.loadResourceScript (RT.java:372)
        clojure.lang.RT.load (RT.java:459)
        clojure.lang.RT.load (RT.java:424)
        clojure.core/load/fn--6839 (core.clj:6126)
        clojure.core/load (core.clj:6125)
        clojure.core/load (core.clj:6109)
        clojure.core/load-one (core.clj:5908)
        clojure.core/load-one (core.clj:5903)
        clojure.core/load-lib/fn--6780 (core.clj:5948)
        clojure.core/load-lib (core.clj:5947)
Caused by:
IllegalAccessError with-session-classloader does not exist
        clojure.core/refer (core.clj:4249)
        clojure.core/refer (core.clj:4217)
        clojure.core/apply (core.clj:667)
        clojure.core/load-lib (core.clj:5966)
        clojure.core/load-lib (core.clj:5928)
        clojure.core/apply (core.clj:667)
        clojure.core/load-libs (core.clj:5985)
        clojure.core/load-libs (core.clj:5969)
        clojure.core/apply (core.clj:667)
        clojure.core/require (core.clj:6007)
        clojure.core/require (core.clj:6007)
        cider.nrepl/eval7095/loading--6721--auto----7096 (nrepl.clj:1)

This seems to be due to an inconsistency between shadow-cljs and calva cider-nrepl versions, if I downgrade calva to .232 version, there are no warnings

Please note, everything seems to work fine even with the warning, but I thought it could be interesting to track this down

Now my problem is where do I report this ?

Furthermore, I noticed a documentation lag regarding Jackin dependency versions and was willing to make a pull request fixing that, but CONTRIBUTING.md mentions basing doc PR against master branch and I an’t seem to find it, has this change to published ?

All PRs should be directed agains the dev branch as far as I know. As for the problem: I’ve got shadow 2.15.5 running with the latest Calva and don’t see that warning. Do you have a repo I could try?

Oh, I somehow misread shadow last version number, let me try again with a more up-to-date version

Ok, sorry about that, the error was on my side, I forgot how yarn manages dependencies upgrades and as it did not upgrade, thought I was on the latest version, my bad

Anyway, thanks for the help

no problem, happy to help

Happy that it works now!

I am actually a bit confused about where we should direct documentation PRs. The rationale behind directing them at published is that that's where the doc site is published from.

That’s what I thought, as the changes I had in mind relate to an already released version

PR welcome. As well as an update to that wiki page. 😃

I’m on it

Do we mention the current versions on the docs site? If so, we probably shouldn't. It gets out of sync too easily.

yes, https://calva.io/customizing/

as default values for the calva.jackInDependencyVersions setting

And I do agree that this could be burdensome to maintain

maybe a link to default values in the code ?

Now that I think of it, that would be fragile too

I’ll push a PR with a proposed change, and we can discuss it there

Awesome.

I think it is that the default doesn't work. Set it to pprint and you should see the width working.

You can set it to zprint as well, but then you need have zprint dependency available to your REPL.

I set it to zprint and added zprint as an alias I can select when jacking in. It works when I do that. However, when I evaluate a variable from a breakpoint with the debugger, it stops working again

Does zprint not get used in the debugger?

Evaluations results during debugging should be printed the same way as when not debugging. If you can describe details repro steps in an issue, including code, that would help. Does using another print engine make that work?

Inline evaluation results should be sticky until dismissed with ESC or the file is edited.

Hi pez. Thanks so much for your prompt reply.

I would like to keep results even after changing the file. Is that possible? (I am new to Clojure and it is useful to compare the results of different functions as a learning tool.)

The closest I can think of is that there are some Evaluate to comment commands.

I can elaborate a bit now. The reason the inline display is reset at edit is that I didn't have the time to figure out how to recalculate the position as the document is edited. It is certainly possible, but the work needs to be done. And the solution needs to be maintainable.. A lot of the code around this is quite messy, it is actually a proof of concept that was released. I think we're reaching a point where we need to refactor/rewrite it and then we should certainly also consider how we can add this recalculation of decorator positions.

I am a beginner programmer (3 years). Coming from python. Always intrigued by the Lisp family. The amount of detail that goes into writing software and the tools to write software is just mind-boggling to me. It really is staggering.

> recalculate the position as the document is edited Aha, I noticed this with Proto REPL. The eval results are sticky but they start to “jump” when an adjacent REPL output window auto-scrolls. Thanks for pointing out the recalculation bit. That's how naive I am -- I didn't even think of that and it explains why Atom starts to lag when I've not cleared the results. I am always learning so much. (The benefit of being a beginner.) Thank you, pez.