Clojurians Log v2

https://twitter.com/borkdude/status/1388193273630576640 you can navigate to re-frames sub and events. Is this something that could work with Calva as well? As far as I understand it is using both clojure-lsp and clj-kondo, so in theory it should, but I wasn't able to get it to work. One thing I noticed is that @borkdude is using namespaced event names in the linked tweet, is that necessary for this to work? I also checked the PR that adds support for this for clj-kondo and from the https://github.com/clj-kondo/clj-kondo/pull/1266/files#diff-f591b825c81f488c7fa9426a07ba9dd30f948cc52e445be929d5fd8299bc7ddeR1646 you have to import the re-frame's functions directly from re-frame? So using you own wrappers around these functions would probably not work?

@mitja.bezensek Correct, you have to use the re-frame functions

But you can always do find-references on any keyword

yeah, that's what I'm using right now just quickly tried to replace references so that I used re-frame.core ones but it's still not working will try to start an new project to rule out issues with our configuration

created a new project using lein new re-frame lsp-test +kondo this template uses re-frame functions directly and also uses namespaced events / subs, but I'm still not able to get it to work

did you create a .clj-kondo directory in the root of the project?

yeah, it's there

is there also a sqlite db in your .lsp dir?

yes there is

ok I will try locally

I see the issue. It works after I visit the events.cljs namespace.

The reason for this is probably that there is no deps.edn or project.clj in this project

And so lsp doesn't know what files to scan

cc @ericdallo

for me it doesn't work after visiting that namespace go to definition for other function does work though

for me it did work

I recommend moving your deps to deps.edn for now

and tell shadow to look for the deps over there

couldn't get it to work. might be just me incorrectly setting things up though 😅 do you have an example repo where it should work?

I just followed your lein new command

To reproduce again:

lein new re-frame lsp-test +kondo
cd lsp-test
echo '{}' > deps.edn

must be something else, this does not work for me

I bet it's an LSP config issue. Are you in emacs?

vscode + calva

this is the clojure-lsp server info

I'll defer you to @ericdallo or @pez now because I can only speak for clj-kondo and/or emacs.

thanks for help! hopefully we can figure it out 🙂

I see that clj-kondos version is 2021.04.23, could that be an issue?

could be!

it seems you still have an old lsp server

updated both, no luck unfortunately

will see if @ericdallo or @pez might know more, thanks again!

hm, I did update clj-kondo and clojure-lsp via scoop but seems like calva is still using the older versions here's the server info after the update

looking into how to update it

Calva uses its own clojure-lsp, there is a Calva setting for selecting which version it should download.

WORKS!

based on your suggestion I added this to vscode's settings.jsons "calva.clojureLspVersion": "2021.06.01-16.19.44",

thanks to both of you!

@pez why was Calva using an old one

Question mark (ffing phone)

We haven’t bumped the version since a while. Maybe we should have a settings for following latest, @brandon.ringe?

Looks a good idea @pez

@mitja.bezensek By the way, there is a command in Calva to get just the server info. I'm not sure if you were using that or not. Calva Diagnostics: Clojure-lsp Server Info.

@pez @ericdallo Do you mean adding a setting that would allow the user to opt-in to Calva always using the latest clojure-lsp version? I'm not sure if that's a good idea, or at the very least, it should default to not automatically using the latest version. Sometimes (though hopefully not often), things may not work well between Calva and the latest clojure-lsp - but if the auto update is opt-in, maybe this is not that big of a deal - the user decides they want this risk for the benefit of always using the latest clojure-lsp. The version setting serves this purpose, but just makes it more of a manual opt-in process. I think right now I'm in favor of keeping it this way, but I'll update the default version used by Calva to the latest.

I'd say Calva could include something in its build to update clojure-lsp to the latest before release. Being a couple of releases behind seems like a bad default.

Yeah, or maybe make it clearer for users that they have outdated clojure-lsp

I think that the current scheme assumes that we Calva devs “vet” the clojure-lsp versions and decide when they work well enough with Calva to be included as default. But in reality we don’t have this capacity. We bump the clojure-lsp version more based on exciting new features. 😃

And only if we happen to pick up on the news of such features.

> I think that the current scheme assumes that we Calva devs “vet” the clojure-lsp versions and decide when they work well enough with Calva to be included as default. Yes, though admittedly we don't vet every feature. Maybe we just make sure it starts up fine and a few things work.

Anyway, we don’t need to make latest the default. But giving the users that options seems cool to me.

And, really, the root problem here is making it more obvious that Calva is using its own clojure-lsp. I’ve seen quite a few trouble shooting reports, including @mitja.bezensek’s above, where brew (or the equivalent) is tried.

Is Calva using another version of clojure-lsp, on top of what the user chooses to use?

Not easy at all… Maybe we should have a clojure-lsp status bar button side by side with the nREPL one? Then we can have tool tips and menus and stuff.

I think it would be time-saving for all of us if the user knows they're not using the latest lsp/kondo somehow

This sort of relates to using libraries in a project though, I feel. Would you always want your build tool to install the latest version of your deps when you build your project? I would think not for the sake of determinism. But, of course, this is a bit different.

It’s not wether they use latest. It is that they are using something Calva maintains.

But either way I do agree we need to make it more clear that Calva is not using their installed version of clojure-lsp

Unless they use the path setting to make Calva use it

@brandon.ringe I am fully ready to not make latestthe default. I’m just suggesting making it an option.

Calva should probably explicitly print these versions in the welcome message if it doesn't already do so

I get that, I was more directing that toward @borkdude. Just curious on his thoughts there.

I don’t think anyone reads those welcome messages.

Or, anyone, is not right. But most people don’t.

at least you can ask them to copy-paste what it says there in case of an issue like this. that would have saved me time today ;)

Ah, that’s of course very nice to be able to ask for.

Well that's what the server info command is for, and that's documented 😄

That was my point, just some window with basic info of clojure-lsp/calva version so most issues we just ask the info from that window

Yeah, maybe the server command is good enough

We just need to ask that first

The welcome message is probably very good for this.

Yeah

Maybe add to the issue template as well

We can put it in the welcome output window message too

We will prove @bozhidar wrong when he says you can’t decomplect using documentation. 😃

Instead of "did you try turning it off and on again" we can say: "please post your welcome message"

or we can even write a bot for it! 😼

copying … wait, this says … you know what guys? I solved it myself. 😃

Calva v2.0.200 is out now, which uses the latest clojure-lsp. I also added a note near the top of the clojure-lsp doc about Calva determining the version by default, the server info command, and how to change the version used. Also added that Calva does not use the version of clojure-lsp installed, unless it was set to do so. https://calva.io/clojure-lsp/

I'll leave the updating of the welcome message up to @pez