Clojurians Log v2

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

Thank you! Tangentially related: If I have an alias :calva in my project deps.edn, and I jack in using that, the REPL is launched with

clojure -Sdeps '{:deps {nrepl/nrepl {:mvn/version "0.8.3"} cider/cider-nrepl {:mvn/version "0.25.6"} clj-kondo/clj-kondo {:mvn/version "2020.04.05"}}}' -A:calva

clojure -Sdeps '{:deps {nrepl/nrepl {:mvn/version "0.8.3"} cider/cider-nrepl {:mvn/version "0.25.6"} clj-kondo/clj-kondo {:mvn/version "2020.04.05"}}}' -A:calva-user -m nrepl.cmdline --middleware "[cider.nrepl/cider-middleware]"

{:extra-deps {nrepl/nrepl {:mvn/version "0.8.3"}
                       cider/cider-nrepl {:mvn/version "0.25.6"}
                       clj-kondo/clj-kondo {:mvn/version "2020.04.05"}
                       vlaaad/reveal {:mvn/version "1.2.185"}}
          :jvm-opts   ["-Dvlaaad.reveal.prefs={:font-size,48}"]
          :main-opts ["-m" "nrepl.cmdline"
                      "--middleware" "[vlaaad.reveal.nrepl/middleware,cider.nrepl/cider-middleware]"]}

Hmm I'm not really sure. Can you send your full deps.edn?

this is ~/.clojure/deps.edn

So you're saying when you name that calva-user alias just calva the jack-in command is different? I feel I remember something to do with hyphenated alias names. I'm going to defer to @pez on this. Maybe he has some more info.

I will definitely check the name thing, but the distinction i meant is where the alias is defined. The one I called calva is defined in the deps.edn of the project, and the one I called calva-user is defined in the user deps.edn file. What I’m not sure about is why the REPL launch string is any different, I was surprised Calva even realized there was a difference.

Calva doesn't even know the user deps.edn exists. So the difference there is probably one of not having the alias defined vs having it defined. To tell Calva about aliases it should use at Jack in, I think the menuSelections property in custom connect settings is the only way. https://calva.io/connect-sequences/

I added a link to several configuration options to the PR incase they are of interest https://github.com/practicalli/clojure-deps-edn/blob/live/deps.edn#L507-L542

@allaboutthatmace1789 I had a bug when using hyphenated names for aliases specifically when adding the alias via calva.replConnectSequences , but adding the same alias into the deps.edn local to the Clojure project works with hyphenated names (sorry, should have raised an issue)

Ah, yes, that too.

Does any of those ^ help you, @jarvinenemil?

Does the output of running unit tests in Calva only show in the repl output window? I am sure I have seen a notification popup in the bottom right corner that shows test results? Was that Clover rather than Calva or did I miss a trick in configuring Calva?

It has happened again. I opened vs code, changed something in the project.clj, jacked in, and this is the output:

It definitely does do that in Clover.

With Calva 2.0.151, linter is flagging this: #_:clj-kondo/ignore (defrecord Slug [rowid src target supp lrd-from lrd-to nseen]) with the error Unused declaration: Slug clojure-lsp(unused-public) Slug is in fact used in the program via the conversion function ->Slug When I use the command-line clj-kondo --lint on this file, however, it lints OK with no errors. How do I suppress the error message in Calva?

Apparently that warning isn't coming from clj-kondo, but from clojure-lsp

How do I suppress it?

Not sure we can disable that as probably is a bug in clojure-lsp

But you can try setting linters :unused-namespace-declarations

Check linters for more info here: https://clojure-lsp.github.io/clojure-lsp/settings/

Thanks, will try.

I tried without hyphen, i.e. called the alias just calva in .clojure/deps.edn. It's still launching with the same args:

clojure -Sdeps '{:deps {nrepl/nrepl {:mvn/version "0.8.3"} cider/cider-nrepl {:mvn/version "0.25.6"} clj-kondo/clj-kondo {:mvn/version "2020.04.05"}}}' -A:calva -m nrepl.cmdline --middleware "[cider.nrepl/cider-middleware]" 

Should mention, I'm launching it by adding :calva to the Calva: My Clj Aliases setting

Which args do you want it to launch with?

When I launch it with that alias in the project deps file, it launches with this;

clojure -Sdeps '{:deps {nrepl/nrepl {:mvn/version "0.8.3"} cider/cider-nrepl {:mvn/version "0.25.6"} clj-kondo/clj-kondo {:mvn/version "2020.04.05"}}}' -A:calva

They start the nrepl server so that Calva can provide its services. Since the alias you provide has it’s own main options, Calva does not add its default main options to the command line. There can only be one main. 😃

I'm sorry, I'm not following. I get that there can only be one main, what I don't get is why -m nrepl.cmdline --middleware "[cider.nrepl/cider-middleware]" is being added in one case (where the alias lives in .clojure/deps.edn) and not where the identical alias lives in the project deps file

That is because Calva does not read the alias definition in the user profile, so it can’t see that there is a main option there. There used to be docs about this. Not sure when we lost them…

Ahhh. So if it's in the project deps, Calva can figure out that the alias has main opts, and chooses not to add it's own. But if it's in the user deps, it can't get to it, so it thinks it needs to add them.

Yes. Well worded. If you feel up to, I’d welcome a PR to the docs so that this behaviour is not as secret as it is today.

Thanks, if I get a chance later today I will give it a go

Is there a reason Calva uses a single ; for comment lines? Or am I doing something wrong and comment lines do start with the usual ;; double semi-colon ? I didn't find a way to customise the line comment, except by hacking `.vscode > extensions >betterthantomorrow.calva-2.0.151 > clojure.tmLanguage.json

"repository": {
		"comment": {
			"begin": "(?<!\\\\);;",
			"beginCaptures": {
				"0": {
					"name": "punctuation.definition.comment.clojure"
				}
			},
			"end": "$",
			"name": "comment.line.semicolon.clojure"
		},

No particular reason except that if it starts with ;; it also starts with ;. I don’t think I quite follow when this is significant?

It is only shown in the Output window. I don’t think we have ever shown it in some other way. Though @marc-omorain once started a PR where the results where shown in the side bar. Today I think we would write a TestExplorer integration to achieve that.

The problem that I hit in my PR was the lack of docs for the cider / nREPL / clojure.tests integration.

It added the results to the Test Explorer pane.

https://github.com/BetterThanTomorrow/calva/issues/953 Added this for the future :simple_smile:

@agold Would you mind creating an issue in the clojure-lsp repo for this scenario?

At least, I think @ericdallo would agree 😄

Yeah, when @snoe finish the 100% clj-kondo integration, we could probably ignore that on clj-kondo level, but ATM it's clojure-lsp linter

BTW, did my suggestion above work @agold?

Is there an option to disable the clojure-lsp linting via a config? They can always just enable the clj-kondo extension I guess

(I have a feeling I asked this earlier this week ;))

Haha, no there is not. If this continues to be an issue I may add that

Yes ☝️

It's a code that should be removed as soon we merge clj-kondo 100% integration so we should avoid improving it unless the merge takes too long

I see, makes sense

Is there anything that is currently missing to accomplish this? Let me know

I think there's nothing on clj-kondo side, @snoe it's WIP on this: https://github.com/clojure-lsp/clojure-lsp/pull/176

Does kondo inform of unused publics? I remember that being a difference in it and what clojure-lsp offered. Like if I have (def x 1) in ns foo and it was not referenced anywhere in the code base, clojure-lsp would say unused public, but if it was referenced in ns bar it would not warn. And from what I remember kondo did not check references outside of the current file? Maybe I'm mistaken

I think is something @snoe was working on clj-kondo, maybe @borkdude can tell us

@brandon.ringe clj-kondo doesn't do this by default, since it works with an open world view: it doesn't have a concept of "I now know everything about your project". But you can easily use clj-kondo's analysis output to do this. Here is an example: https://github.com/clj-kondo/clj-kondo/blob/master/analysis/README.md#unused-vars

The references outside the current file: it does have this concept, e.g. you get arity errors about vars in other namespaces.

There is an issue I'm working on right now to detect references that are unresolved in other namespaces. e.g. set/onion

So clojure-lsp would need to keep providing at least these specific diagnostics if it wanted to keep them, right? If it stopped providing all diagnostics in favor of only kondo diagnostics, I think this specific case, at least, would be lost.

CC @ericdallo. Just hoping not to lose something 😄

Yeah, the idea is not lose these diagnostics! we should use the kondo analysis to make that work

@ericdallo No, your suggestion didn’t work. I am using a workaround: (when nil (form that uses the supposedly undeclared thing))

thanks, I'll check that later, open a issue on clojure-lsp could help to track that

Thanks!

I’ve just noticed that I’m getting a clj-kondo warning saying that my -main function is an unused declaration. This certainly wasn’t happening a while ago, but I’m not sure when it did start. I’ve recently moved away from building with Leiningen and am now building with deps.edn which might be the cause? Or perhaps it’s something that’s changed within Calva? I’d welcome a nudge in the right direction.

this is probably not clj-kondo, but clojure-lsp saying this

Ah! Yes “Peek problem” says “clojure-lsp(unused-public)”

Nevertheless, it’s definitely new? Any idea why I’ve started getting the warning? And how to quieten it?

@paulbutcher See this convo earlier today: https://clojurians.slack.com/archives/CBE668G4R/p1610825790090000?thread_ts=1610814290.076400&cid=CBE668G4R

Thanks. And now that I know where to look, I can see that clojure-lsp was introduced into Calva last month, which explains why I’m getting the warning when I wasn’t before.

Yes, good news is that we are working on that PR and we ll try to merge it ASAP 🙂 https://github.com/clojure-lsp/clojure-lsp/pull/261