Clojurians Log v2

calva + WSL2 also works well for me, except it has some trouble running kondo. I keep getting Couldn't start client clj-kondo 😞 can anyone help?

That message seems to be coming from the clj-kondo extension. (At least it does not come from Calva, afaict.)

@levitanong what do you see in the clj-kondo output window?

-- Welcome to clj-kondo v2020.07.29.
--
-- To configure clj-kondo, create a .clj-kondo directory in the root of your workspace and place a config.edn file in it.
-- Check out the configuration documentation here: <https://github.com/borkdude/clj-kondo/blob/master/doc/config.md>.
--
-- If you have questions, join the #clj-kondo channel on Clojurians slack.
-- Report issues at: <https://github.com/borkdude/clj-kondo>.
--
-- Happy linting!

[Error - 2:52:04 PM] Starting client failed
Launching server using command java failed.

Maybe you don’t have java installed?

I get this message in the output Window: "clj-kondo was not found on the classpath. Debugger decorations will not be enabled. More details: https://calva.io/debugger/#dependencies" But clj-kondo seems to be working just fine, so I ignored it.

Are you using shadow-cljs?

Yes

This should have been in the reply to @levitanong above. It applies to Calva on WSL2.

It is a confusing message anyway. 😃

👍

@agold are you able to use clj-kondo as a CLI in WSL2?

I haven’t needed to it, as I use it only for linting in Calva, which works fine. And I haven’t used the Calva debugger, so I don’t know if the msg about the debugger is meaningful.

There is no debugger for cljs. So the message is not meaningful.

😀 Right, I forgot that!

kondo is used in two ways currently. The bundled extension, and then an injected version that we use in the debugger to sort out vars and stuff (@brandon.ringe knows more about this). But for users this latter thing is not known, so the message gets interpreted as if there could be problems with linting… We’ll fix that message. 😃

@levitanong: fyi, I just downloaded and installed clj-kondo as instructed on the GitHub page, and it works fine in WSL2.

Anyway, to @pez and @borkdude, a million thanks. Calva and clj-kondo make developing cljs a pleasure, and Calva just keeps getting better. I used Emacs/Cider for many years and loved both, but my .emacs file was getting to the point where I was afraid that the whole contraption might fall apart with the next update. VSCode just feels like a more solid base.

Sweet. Thanks for letting us know! And since you are a WSL2 user, I think that answers @borkdude’s question very nicely from a perspective of someone who would love a Calva shoutout. ❤️

<3

I actually use Calva not only on WSL2 but also Mac and straight-up Linux and have found it quite trouble-free on all 3 platforms. Another plus for me is that it is much less painful to keep my VSCode settings in sync across platforms than it was with Emacs, where there were more platform-specific gotchas. My only gripe is that some of the paredit keybindings don't work properly on the Mac, but at the moment I can't remember which ones. I'll file an issue when I go back to working on the Mac. Right now I'm mainly on WSL2 (for the past week or so) and so far no issues at all.

It’s not these shortcuts? https://calva.io/quirks/#macos-and-the-slurp-and-barf-keyboard-shortcuts

No. My memory is vague, but I think it may have been the splice-and-kill-backwards/forwards commands. Not quite sure. In any case, no big deal, and it may be my screwup. Will file an issue if needed when I have time.

Possibly relevant: I'm using a Mac laptop , where the Delete key is actually Backspace and there is no actual Delete key (fn-Delete gives you delete), so commands that are listed in Calva kb shortcuts as using Delete don't work as advertised. If I recall correctly.

Hmmm, they do on my MacBook. (I use fn-backspace to produce delete, as you say there.)

I will try again. Seems to require some manual dexterity to do alt-shift-fn-delete or whatever chord is required for some commands.

Oh, yes. The shortcuts could be much improved. I’ve been stubborn in trying to keep he default ones cross plattform, but the price is too high.

Ah yes, a bad decision of mine to print that error, in retrospect. I'll create an issue and remove it soon, and instead let the docs do the talking in that respect. I've seen multiple questions about it at this point (confusion).

My reasoning was that if clj-kondo is not on the classpath then debugger decorations will not work (highlighting instrumented functions) and the user may be confused / think it's broken, but since this isn't a super widely used feature, and it's only for clj, it makes sense not to bark about it in the output.

Is there a way we could bundle clj-kondo the command, and use it that way? Then everyone gets debugging even if they do not provide the deps in their projects.

"The command" as in "the binary" is not needed with VSCode, it's all Java, LSP server remember

Yeah, the command as in java ... 😃 . The way the clj-kondo extension does it.

oh right

Or if you add an api to the extension, Calva already depends on it.

I vaguely remember @borkdude suggesting the JVM lib was the better option for my use-case, but maybe I'm mistaken, and I don't remember the reasoning besides maybe performance? It's called fairly often, but then again does the clj-kondo extension perform linting this way? I'd love to remove that dep injection in the jack-in and have it behave the same if possible

Oh also, I needed the lint analysis

need*

@brandon.ringe clj-kondo in VSCode starts an LSP server. This is only started once per workspace

So only one JVM per VSCode window mostly

I see. So here is my use case

const code = `(with-in-str ${JSON.stringify(documentText)} (:analysis (clj-kondo.core/run! {:lint ["-"] :lang :clj :config {:output {:analysis true}}})))`;

Is there another way?

doing it via the REPL is convenient, for startup

if there is no REPL, you could maybe start one yourself?

Or maybe you can adopt the LSP server model from the clj-kondo plugin

but for Calva purposes

Yeah, starting a new repl is another option, but it's used for something that only makes sense when a repl is connected, so I just used the one started by the jack-in process. Starting another repl completely seems a bit heavy-handed, as I imagine another terminal/pseudoterminal would be necessary and might confuse the user. I don't want to depend on the plugin, in case someone disables/uninstalls it (don't want this feature to break). Maybe that is not what you are suggesting.

I've also wondered if clojure-lsp can provide me with what I need, but integrating that is still on the todo list

The user can't disable uninstall clj-kondo w/o first disabling Calva.

This is a mistake in the current Calva conf, but you could depend on it and then we don't need to fix the mistake. 😃

I don't know when that dependency was added, actually. It is quite odd.

@brandon.ringe No, that wasn't what I was suggesting. My suggestion was to copy what clj-kondo is doing running as an LSP server, but it its output for Calva

So not depending, but forking the plugin code

This will mean an extra JVM as well

so, I'll leave those trade offs up to you

Ah I see. Thanks for the info. We can ponder this, but for a single call, I think what we have works fine for now. Just need to remove the confusing message.

The message is actually what you need if you don't use jack-in, right?

The message displays if, on repl connect, clj-kondo is not found on the classpath (really the code requires it, and if error, displays that message). So not just about jack-in, if the user connected to some repl started without jack-in that has clj-kondo as a dep, then decorations would work and that message would not show