Calva Gets Static Analysis Features via Clojure-lsp

[bpringe]

With help through funding from Clojurists Together, Calva has gained new features by integrating clojure-lsp. Some of these have been in Calva before, but only worked through an nREPL connection with proper dependencies. Version 2.0.137 introduces the following features, which work without an nREPL connection.

• Go to definition/references
• Peek definition/references
• Find all references
• Rename symbol
• Change all occurrences
• Hovers
• References code lens, that peek references when clicked (enable in settings)
• Outline view

Over the coming weeks we plan to add more features from clojure-lsp, like intellisense and refactorings. Join us in the #calva channel in the Clojurians slack if you’d like to chat, and report any bugs or feature requests as issues on the Calva repo.

Thanks to Case Nelson (@snoe), Eric Dallo (@ericdallo), and other contributors to clojure-lsp. Also, thanks to Calva users who provide valuable feedback, ideas, and testing. You help drive Calva forward.

[didibus]

What kind of project setup does it need to work? Can it detect the VSCode project itself to find source files and dependencies? Or does it detect it from a deps.edn file? Or a project.clj file? Does it support Boot projects as well?

[bpringe]

It can detect some things by default, but you can also configure project settings in a .lsp/config.edn. See here for more info, notably settings like source-paths and project-specs. It does support boot projects as well.

[PEZ]

Super awesome work @bpringe! And I want to chime in on your thanks to @snoe and @ericdallo.

I’ve celebrated these new Calva powers and Christmas Day with reaching in to clojure-lsp's refactoring support and added these refactoring to Calva.

• ‘clean-ns’
• ‘add-missing-libspec’
• ‘cycle-privacy’
• ‘expand-let’
• ‘thread-first’
• ‘thread-first-all’
• ‘thread-last’
• ‘thread-last-all’
• ‘unwind-all’
• ‘unwind-thread’
• ‘introduce-let’
• ‘move-to-let’
• ‘extract-function’

Or, they are for now only in PR mode, I need to test it some before releasing. You all can help testing it by installing this VSIX in your VS Code: https://9293-125431277-gh.circle-artifacts.com/0/tmp/artifacts/calva-2.0.138-pez-refactorings-3c4b9247.vsix

Please see https://github.com/BetterThanTomorrow/calva/wiki/Testing-VSIX-Packages for how to easily try out dev Calva VSIX builds.

[ericdallo]

Awesome work! An amazing integration that will improve both libs

[teawaterwire]

so grateful - thanks a ton!!

[practicalli]

Exciting future for Calva ahead, congratulations.

EDIT: Be aware that clojure-lsp currently consumes additional memory whist the clojure-lsp process runs, although this should only be for less than a minute (usually much less). The greater number of dependencies a project has, the more memory seems to be consumed and time taken. I have had several projects with a large number of dependencies that consume over 3Gb of RAM when clojure-lsp is run by Calva, but hopefully these are the exceptions.

There is currently no way to prevent clojure-lsp running in Calva (except downgrading to version 2.0.136 where it is not used). It is very welcome to see many people involved in efforts to reduce the memory footprint and other improvements to the experience.

Reduce memory usage

Another potential issue to be aware of is multiple instances. If VS Code is restarted (i.e. when a new version of calva is available) whist clojure-lsp is running, it may not terminate that process. Check your system monitor for java processes using larger amouts of memory if you have issues.

The clojure-lsp process does run in a background thread, so if your computer has more than 2Gb of free RAM it should not affect performance at all (or you can step away from your computer and get a cup of tea).

Add setting for disabling clojure-lsp

Clojure-lsp does give the opportunity for editing functionality (not REPL functionality) to be common across all Clojure editors and I hope that clojure-lsp continues to evolve to be a common tool for Clojure development. It does seem that with Calva’s move to LSP there are more visible signs of activity around this interesting project

Thank you to all involved.

[bpringe]

Thanks for the congrats.

Be aware that clojure-lsp currently consumes a minimum of 2Gb of memory each time the clojure-lsp process runs, regardless of the size of Clojure project.

I just want to point out that this is not true. I’ve yet to see clojure-lsp use more than 2Gb, though I’m not saying it doesn’t happen. The memory usage I think can be reduced though, and I’m hoping to see that happen soon as well as help with it if/where needed.

[bpringe]

If VS Code is restarted (i.e. when a new version of calva is available) whist clojure-lsp is running, it may not terminate that process.

The issue with clojure-lsp processes not being killed when VS Code is killed/restarted while clojure-lsp is starting has been fixed in version 2.0.146.