It seem to be a law of physics that as soon as you ask a question, you find the answer yourself 🙂. It's a pprint issue. settings.json -> calva.prettyPrintingOptions -> maxLength

For one-off situations, you could also just disable pprint. There is a command Toggle Pretty Printing ..., or click on pprint in the statusbar.

Usually classpath issues, check https://clojure-lsp.io/troubleshooting/#some-features-are-not-working

That seems to come from clojure-lsp

Usually when clojure-lsp classpath is not right

In a clojure not bb buffer does it work for comparator?

@U0522TWDA which version of Calva are you using?

Version: 2.0.319 And yes, in a non-bb project the docstring works

is it possible to create a sample project so I can test ?

will try

@UKFSJSM38 I have a folder with a single test_helper.clj containing

#!/usr/bin/env bb
(compare 1 2)

so probably the project root is wrong, making clojure-lsp not run bb print-deps to build the classpath

check https://clojure-lsp.io/settings/#classpath-scan for more info

true. If I echo '{}' > bb.edn and restart code then the docstring shows up.

Yep, that's a known "limitation"

Now I know about this hack and my babashka-ing will be much more pleasant 🙂 Thank you for your help!

there is no way clojure-lsp know your project is a valid bb one if there is no bb.edn present Glad it works!

Well, perhaps Calva could tell it it is, when I start a bb repl there? @U0ETXRFEW

unfortunately is not that easy, the classpath discovery on clojure-lsp is done enterely on server, we would need to receive some flag and make things harder, for now having a simple bb.edn seems fine enough

I often make one off babashka scripts, without bothering with dedicated directories or extra files. But I can have one script directory for developing them with a dummy bb.edn…

If we wrote out an empty bb.edn before starting LSP, and then deleted it, would everything work as expected in this scenario?

I guess you would also need to tell lsp to re-start its work after you write it?

You can restart LSP with Calva Clojure LSP: Restart the Clojure LSP Server command from the command pallet. I was talking about maybe Calva being a bit smarter. Unsure whether everything (including non-lsp features) works correctly if we delete the bb.edn after LSP is started. If the file would need to be permanent, we might as well leave that to the user to add necessary files to their projects. But if we only need it while starting LSP, that sounds like a nice (fairly lightweight) feature: Calva could recognize a bb file with no bb.edn as needing a bb.edn next to it long enough to start LSP.

@U0ETXRFEW, would that work? I'm sure @U0522TWDA would be happy to write up an Issue for it (and maybe a PR too? @U0522TWDA 🙏 ).

it'd probably work, sounds a little bit hacky though I guess

TBH not sure worth having this magic, the docs are clear that is a file required

Perhaps calva could just flesh a large "RTFM!" when starting bb project repl in a å folder without bb.edn?

Which docs? Not bashaska, right? For babashka, bb.edn is only required for certain features. If the user doesn't need those features, why should they be forced to add one to get editor support? On the surface, the answer is obvious: "because we rely on Clojure LSP, which doesn't support that, and adding that support to LSP is too much work for too little gain". But if we have a way to provide that support with a little minor trickery at the editor level, that seems like a good thing to me. It doesn't seem that magical to me. It is the same solution the user would use, except without leaving that otherwise useless file laying around on their filesystem.

yes, clojure-lsp docs Yeah, I can see how convenient, it may worth it, I hope it doesn't make things more complex or make it harder to debug issues like this one

> I hope it doesn't make things more complex or make it harder to debug issues like this one Agreed on the concern it could turn out overly complex. But if @U0ETXRFEW agrees, I think it is certainly worth at least taking a look at. It would definitely make debugging this particular issue easier, since in this scenario everything would "just work". 😄

I like the idea. Calva knows you are connecting to a babashka REPL 1. sees that the bb.edn file is lacking 2. creates it 3. restarts clojure-lsp 4. deletes it Magic, but maybe that is fine?

Just careful with the delete in the case the user has changed the file...

The delete would only happen in the case Calva created the file. It would not be there long enough for the user to change anything unless they went out of the way to have an unsaved bb.edn file open to quickly save during LSP startup. @U0522TWDA Please file an issue on https://github.com/BetterThanTomorrow/calva/issues describing your initial concern that led to this conversation (that LSP features don't work on bb files without bb.edn). And if you feel up to it, I know @U0ETXRFEW is always happy to look at pull requests.

The idea to tie it to jacking in to a bb repl seems nice, for limiting the scope of when to check for this. We would need to ensure that LSP restart is running concurrently to connecting to the repl, or jacking in will become painfully slow in this scenario.

I have created https://github.com/BetterThanTomorrow/calva/issues/1968

I don't understand the question. 😃

Code in cljc files is written to run in multiple environments. Looking to run tests for that code in all envrionments intended to be supported. Would be great if that can happen all at once through the Calva test runner while working in the editor.

I'm guessing if you don't understand the question, you probably haven't thought about it yourself already, and thus unlikely to be currently supported. 😄

Since Calva's eval works by running tests in a connected REPL, you'd need both a cljs and a clj REPL active. But you couldn't have "all" environments (like multiple versions of Clojure, or with different aliases to control behavior) because you can only have two REPLs I think.

Makes sense.

I didn't understand the question, because I've never heard this referred to as environments. 😃

And, yes, Only clj and cljs sessions supported, really. Calva cheats when connected to a Babashka or nbb or Joyride REPL and uses the clj session for that.

What I do for cljc files is that I configure a test build in shadow-cljs to autorun tests. Then use Calva's test runner for Clojure. (In fact, I mostly work with ClojureScript, and use shadow's test runner, so am not a heavy user of Calva's test runner at all. (Which is funny, because the test runner is the reason Calva was created in the first place.)

Curious. What would you call it if not environment?

> (Which is funny, because the test runner is the reason Calva was created in the first place.) That is funny.

I don't use Calva's test runner either 🙂 I use clojure.test with a bit of code wrapped around it.

That makes me double down on a thought I had when I first started using Calva: Instead of having its own test runner, Calva should aim toward finding a user-friendly way to report results from whatever test runner(s) the user chooses to configure for the project. I don't know how complicated that would get if test runners are not designed with separate reporters in mind. But that seems like the ideal direction.

clojure.test doesn't really support multiple reporters very well -- it's why, for example, humane-test-output doesn't play well with lein test

(it's really kind of amazing how poor clojure.test is for something that we have all come to rely on so heavily! 🙂 🙂 )

Does this mean no people are hurt during the use of clojure.test? Humane -sorry but its helpful to see the many different test methods.

Just FYI, the Calva test runner only supports Clojure (currently). Maybe that was gathered from what was said above - not sure.