Fork me on GitHub
#clojure-europe
<
2021-01-02
>
borkdude10:01:00

I'm also excited about this and currently reviewing PRs to clj-kondo which will make the static analysis via clojure-lsp even more awesome (it is using clj-kondo as a lib). The funding by Clojurists Together is affecting all of these projects at the same time :)

šŸ‘ 6
clj-kondo 6
pez10:01:08

Yes, and the assistance we have gotten from the clojure-lsp team is totally lovely. We've been able to work fast and iterate together. And I think most of Brandon's (the Calva guy who's funded currently) work has been on the clojure-lsp. In Calva we get a lot of this for almost free since vscode is LSP home turf.

pez10:01:56

It is extra nice with the combo of static and dynamic. So now Calva is a really useful tool for opening and examining a project w/o starting it. Then the analysis gets even better when the repl is connected. And it is then better than it was with only the repl connection. I think we can venture deeper here. If we start using clojure-lsp for linting we will reach clj-kondo's linting powers that way and could add CodeActions to offer fixes for some of the stuff that don't spark joy.

slipset13:01:50

have you talked to @bozhidar about clojure-lsp and cider integrations?

practicalli-johnny13:01:49

I have not had that good an experience with clojure-lsp and Emacs, so far. There is lots of cross-over which leads to conflict in the UI. It seems to require switching off all the conflicting features and unfortunately that has not been documented well as yet.

practicalli-johnny13:01:44

I beleive people have it working, but I dont really understand clojure-lsp terminology enough to understand what is going on. I am also weary of adding IntelliJ-like back-ground processing, which seems bad in Emacs when I tried it a few months ago as it was blocking the Emacs thread.

slipset13:01:34

Right. I guess my main concern is that the find-usages static analysis is so much better than the dynamic one.

slipset13:01:18

As the dynamic one (currently in Cider) doesnā€™t seem to include the line-numbers.

practicalli-johnny13:01:47

Not something I think I use, I seem to rely on the really effective Emacs tools for finding things and refactoring.

practicalli-johnny13:01:36

Hopefully someone will actually demonstrate what you are describing. Its something I never understood, even when using IntelliJ

slipset14:01:13

So in a jacked in emacs, I can press C-c C-? r when on a Clojure symbol. This brings up a buffer with all the references to that symbol. Each occurrence has a ā€œbuttonā€ to push which gets you to the function in which the symbol is used. In Calva and Intellij, this gets me to the line where the symbol is used. I could achieve something similar I guess with cunning uses of grep, (especially because we tend to always use aliases, and donā€™t refer). My grep-fu stops when I have a fn called id in a ns named ardoq.core, Then I would have to figure out all the ways we alias ardoq.core (which as it happens is only core) and then build a grep pattern which finds id both as a qualified symbol (`core/id` ) and as a unqualified symbol (`id`), because Iā€™d have to find the references in ardoq.core as well. Now, this fn could be used in a higher order context like (map core/id xs) and it might be used in a normal context (core/id foo), and both of these qualified (as here) or unqualified.

slipset14:01:32

Iā€™d be happy to elaborate more if thatā€™s useful.

bozhidar14:01:01

I'm well aware of the shortcomings of the current approach in CIDER, although clj-refactor.el already does something quite similar to what clojure-lsp does. Integrating clojure-lsp in CIDER makes little sense directly, as CIDER was designed to be REPL-powered and clojure-lsp opted for the static analysis route. That's also the main reason why I avoided implementing find-references with static analysis in the past as well - I wanted to stick to the core idea and avoid having to deal with the complexity added by the static analysis (e.g. keeping in sync the code and the ast, the initial project indexing and so on). I think the best way to add static analysis to CIDER is how clj-refactor did it (via middleware), but unfortunately the project hasn't been actively maintained for a while now. I'm guessing that it also makes some sense to using clojure-lsp until you jack in, but then again - if find-references are the only major advantage, you can obtain them in a simpler fashion (e.g. by using https://github.com/didibus/anakondo or a similar approach). When I need to look up references I simply use projectile-grep and it gets the job done pretty well for me. šŸ˜„

bozhidar14:01:28

In general - it's not hard to come up with a better find-references for CIDER, but it's hard to find time to work on this.

ā¤ļø 9
bozhidar14:01:26

Anyways, if you have any concrete ideas about improving the usage of CIDER alongside clojure-lsp feel free to share them here https://github.com/clojure-emacs/cider/discussions

practicalli-johnny15:01:02

@slipset If I understand correctly, the static analysis helps with accurate refactoring ? I find it easy to refactor across projects using Emacs tools, e.g. helm-swoop then C-c C-e to edit search results which will save changes back to the original files when finished. https://practicalli.github.io/spacemacs/refactor/within-a-project.html I always using meaningful names, so this works very well in my projects. I dont really understand why people write weak and inconsistently named code, its like they don't really care about anyone working with it. I hope that clojure-lsp doest encourage more weak naming of things

practicalli-johnny15:01:07

@bozhidar I do find anakondo far more usable with CIDER than clojure-lsp (which requires knowing which things to turn off to avoid conflict). I started using anacondo in 2020 I think and the only reason I stopped was it killed startup time. My Emacs setup uses layouts which automatically opens a dozen or so Clojure projects and means any LSP server will reanalyze the projects on startup. This least to over a minute to start Emacs. This would be very bad for live demos should Emacs crash.

slipset15:01:34

@bozhidar I have consistently failed in having expez work on clj-refactor again. Even though he has 10% time to do so at work šŸ˜•

slipset15:01:14

I guess thereā€™s a level of bitrot on that project that doesnā€™t quite suite his palate.

bozhidar15:01:58

I guess so. The project started off strong, but it's slow degraded and now it needs a lot of love, as some functionality has been broken for ages.

bozhidar15:01:06

I'm tackling a few smaller problems there now and then, but I don't even use clj-refactor, so my incentive to spend time on the project, when I'm buried with issues in the other projects is fairly small.

slipset15:01:40

I hear ya.

practicalli-johnny16:01:14

@slipset everything I know about lsp with Emacs so far is in this issue https://github.com/practicalli/spacemacs-content/issues/287 Some of the documentation concerns are to be addressed, although I am unaware of what time frame that will be (I did ask about 8 months ago it seems).

slipset13:01:55

Hmm, this is starting to look really good, @pez. I will have to do a serious round of configuring calva keybindings to my liking.

slipset13:01:29

Oh, add missing require is there šŸ™‚

slipset13:01:37

find occurences too.

pez13:01:12

I know @jr0cket is working with VSpaceCode keybindings. Not sure if that is your cup of tea, but anyway.

slipset13:01:38

Iā€™ll jump on over to #calva with some immediate questions

pez13:01:21

There are some here as well. https://calva.io/emacs-keybindings/ Probably quite out-dated.

genRaiy14:01:35

A Cider dude walks into a bar ... he should have ducked ... welcome @bozhidar

bozhidar14:01:58

@slipset invoked a powerful incantation that ended up summoning me here straight from the pub! šŸ˜„

ā¤ļø 6
šŸ» 3
pez14:01:46

Cheers! calva