Fork me on GitHub
#lsp
<
2022-04-01
>
andrea.crotti11:04:09

is there any magic in lsp that would allow me to convert all the :refer :all to something like :as namespace instead, or just :refer [x y z]

☝️ 1
genmeblog11:04:55

omg, just wanted to ask the same question!

genmeblog11:04:35

I see that clj-kondo returns full :refer [...] list as a solution, you can just copy&paste

genmeblog11:04:45

I would also prefer to have it automagically. Both ways: alias + auto prefix for symbols and :refer as the option

andrea.crotti12:04:03

ah right I didn't even noticed that clj-kondo was suggesting how to replace it

andrea.crotti12:04:11

mm then it should be definitively auto fixable I guess

ericdallo13:04:41

For refer there is, for alias not. Unless we check if that namespace already has a alias across the project

andrea.crotti14:04:40

yeah refer would be enough

andrea.crotti14:04:54

but how do you do it? I checked on https://clojure-lsp.io/features/#execute-command but can't see the right way

andrea.crotti14:04:09

In the end I've done it manually just taking the output of the linter and replacing it which was easy enough

andrea.crotti14:04:21

but yeah would be nice to know

ericdallo14:04:50

we don't have this feature yet 😅 Feel free to open a issue suggesting it, but it'd be available probably via code action when we receive that warning from kondo

ericdallo14:04:29

actually, this could go on clean-ns maybe, but it'd need to be careful not break anything, maybe as a optional flag with excludes for sure

ericdallo14:04:28

@U0BUV7XSA a command/code action sounds good too, but have that on cleans ns with sane defaults sounds a good idea to me too, clj-kondo already warn about refer all anyway

andrea.crotti15:04:44

ah nice I didn't know that cljr could do that

genmeblog15:04:35

cljr has a lot of hidden gems

snoe15:04:51

@ericdallo the larger projects I've been on have had a mix of rules, unit tests get :all, but integration tests don't, some libraries always get refer [..] , I think it's such an aesthetic choice, maintaining flexibility is important

👍 1
ericdallo15:04:52

Sure, I thought something similar we do for lens, exclude smart defaults and have the option to exclude custom ones

snoe17:04:52

yeah, as long as it can be turned off from clean-ns and both exist for those projects without defined rules.

👍 1
andrea.crotti11:04:57

it might be tricky I guess since it would have to match all the unresolved symbols with something defined in one of these namespaces that is referring all

andrea.crotti11:04:14

but I have lots of them to fix, might be nice to find a way not to do them manually

grzm13:04:01

Good morning! I'm running clojure-lsp with emacs. I've noticed that my “squigglies” indicating unused vars (top-level and local) have disappeared. How do I get them back? I don't remember making any changes to my eMacs configuration. I am running the latest clojure-lsp (updated this morning). I don't remember doing anything special when I first started using clojure-lsp to enable them (but those memories are lost in the mists of time).

ericdallo13:04:00

lsp-mode had a recent change changing the face, the diagnostic is stilll there, but the "squigle" is gone, but the symbol is now gray

grzm13:04:15

Another way of framing this question is what configuration controls the squiggles? Is this a flycheck thing? A clj-kondo thing? A clojure-lsp thing? Some combination? It was magical when it was working and I didn't really need to dive in while the magic was working, but it seems the elves have gone and it's time to dig in.

grzm13:04:11

Is there a way to have squiggles instead? The difference between squiggle and no squiggle is much greater than the edit distance between “0 references” and “1 reference”

ericdallo13:04:15

• clj-kondo provide 99% of the diagnostics, clojure-lsp just pass to LSP client (emacs/lsp-mode) and it's shown in the edtiro • clojure-lsp uses a clj-kondo feature to provide a custom linter clojure-lsp/unused-public-var , but to configure that linter you still change clj-kondo config as decribed https://clojure-lsp.io/features/#clojure-lspunused-public-var

grzm13:04:53

Also, I seem to have lost the local unused stuff, too. Not just the top-level “public” vars.

ericdallo13:04:11

so the problem could be other

ericdallo13:04:38

(defn ^:private foo [] ;; unused private function
  123)
this should give that warning

ericdallo13:04:41

could you test it?

ericdallo13:04:50

if no warnings, you have something misconfigured

ericdallo13:04:57

probably in your emacs

grzm13:04:50

I'm away from my machine. I will do. I'm referring to unused vars in let bindings and such. Not private top-level vars.

ericdallo13:04:17

those are too clj-kondo findings

ericdallo13:04:44

That linter is called unused-binding

grzm13:04:05

Okay. When I call clj-kondo on the command line, these warnings are picked up. That indicates it's likely in the emacs clj-kondo configuration, correct?

ericdallo13:04:19

you shouldn't have a emacs clj-kondo configuration, you should use lsp-mode which will use clojure-lsp that will use under the hood clj-kondo for you

ericdallo13:04:36

so you just need to configure properly lsp-mode and install clojure-lsp

grzm13:04:51

(With clj-kondo bundled with clojure-lsp, it kind of blurs the lines for the naïve about which configuration is where)

ericdallo13:04:41

no, because you still configure the clj-kondo part the same way if using clj-kondo only

ericdallo13:04:45

via .clj-kondo/config.edn

grzm14:04:22

From this user’s experience standpoint, something changed the behavior of using clojure-lsp/clj-kondo/lsp-mode. It sounds like it was at least partly due to an upgrade of clojure-lsp. The command line experience of using clj-kondo had been unchanged. I'm hearing that there are things that are clj-kondo configuration, (local var linting, for example) which are working on the command line but not in emacs. I can understand why this seems clear to you: you're living in it. (And thank you for this!) please underhand that for people (or at least me) who do not live/develop this, this is not at all clear or easy to understand when something changes (or “breaks” from the standpoint of the user)

ericdallo14:04:45

np, that's why docs should be updated, LMK if it's not. But we shouldn't break anything related to lint between releases so you can test a previous one and check if it changed anything

grzm14:04:54

I do want to fix it, and have been going through the docs trying to find what it might be. Thank you for pointing that this is likely in my emacs lsp-mode config.

ericdallo14:04:59

also, posting your config may help understand how emacs is behaving for you

pyr14:04:20

Adding to the above, I think I ended up in the same situation. I reverted to a vanilla emacs + only lsp-mode, clojure-mode, lsp-ui, and flycheck (all pinned to melpa-stable) and I find myself in exactly the same situation (after installing lsp-mode, no linting hints are shown anymore)

pyr14:04:06

clojure-lsp --version reports:

pyr14:04:15

clojure-lsp 2022.03.31-20.00.20 clj-kondo 2022.03.10-SNAPSHOT

pyr14:04:39

and likewise, manually running clj-kondo finds linting issues

ericdallo14:04:50

I recommend not using stable lsp-mode, but melpa unstable one

ericdallo14:04:04

we usually take some time to release a new lsp-mode, and we fix lots of bugs all the time

grzm14:04:30

After doing something similar, declaring local emacs bankruptcy and slowing adding things back, and removal of .lsp directories and re-defining lsp projects, I did get the squiggles to come back. For a day. The next day I came back (emacs still running, no changes), no squiggles. I don't know how to inspect the state of what any of these packages think is going on.

ericdallo14:04:15

you can start checking client<->server log to see if clojure-lsp is working good and returning diagnostics: https://clojure-lsp.io/troubleshooting/#client-server-log

grzm17:04:08

So, I think I might have figured out what is going on with clojure-lsp not working (but not why it was working before and stopped working): the source paths in my monorepo weren’t being picked up by clojure-lsp. I’m now creating a separate lsp “project” in each of the modules in the monorepo. The primary tool that helped me figure this out was looking at the output of lsp-clojure-server-info Also, ensuring I have :source-aliases set appropriately to include source paths from aliases other than :dev and :test.

grzm17:04:50

That said, I had it working again a week ago, and then when I came back the next day it was no longer working. So 🤞 that this sticks.

ericdallo17:04:30

@U0EHU1800 sorry, I forgot to mention we introduced on some releases ago a behavior where for projects with wrongly configured source-paths, the diagnostics (clj-kondo lint) stopped working

ericdallo17:04:43

I already made a fix for that, but that just showed that source-paths were probably always wrong 😅

ericdallo17:04:26

also, I recommend starting clojure-lsp at the root of the mono-repo, usually clojure-lsp detects automatically, if not, you can configure iwht :source-aliases or :source-paths

ericdallo17:04:34

clojure-lsp project itself is a monorepo and it works nice, LMK if you need help configuring that, I just need to understand the project structure

ericdallo17:04:14

I suggest you testing #clojure-lsp-builds for that diagnostics fix I mentioned

grzm13:04:15

Another way of framing this question is what configuration controls the squiggles? Is this a flycheck thing? A clj-kondo thing? A clojure-lsp thing? Some combination? It was magical when it was working and I didn't really need to dive in while the magic was working, but it seems the elves have gone and it's time to dig in.

rafaeldelboni17:04:08

Hey I'm trying to use the new go to definition to java features and I'm getting this in the logs 🧵

rafaeldelboni17:04:16

2022-04-01T13:32:50.212Z  INFO [clojure-lsp.feature.java-interop:183] - [93m[Java][0m Local JDK source not found.
2022-04-01T13:32:50.212Z  INFO [clojure-lsp.feature.java-interop:188] - [93m[Java][0m Found local JDK source URI, extracting to global LSP cache dir...
2022-04-01T13:32:50.212Z  ERROR [taoensso.timbre:828] - Uncaught exception on thread: async-dispatch-2
[37mcom.oracle.svm.core.posix.thread.PosixJavaThreads.pthreadStartRoutine[m  [32m      PosixJavaThreads.java:  194[m
            [37mcom.oracle.svm.core.thread.JavaThreads.threadStartRoutine[m  [32m           JavaThreads.java:  597[m
                                                 [37mjava.lang.Thread.run[m  [32m                Thread.java:  829[m
                                                                  [37m...[m  [32m                                 [m
   [33mclojure.core.async.impl.concurrent/counted-thread-factory/reify/[1;33mfn[m  [32m             concurrent.clj:   29[m
                   [37mjava.util.concurrent.ThreadPoolExecutor$Worker.run[m  [32m    ThreadPoolExecutor.java:  628[m
                    [37mjava.util.concurrent.ThreadPoolExecutor.runWorker[m  [32m    ThreadPoolExecutor.java: 1128[m
                                                                  [37m...[m  [32m                                 [m
                                   [33mclojure-lsp.handlers/initialize/[1;33mfn[m  [32m               handlers.clj:  115[m
         [33mclojure.core.async.impl.ioc-macros/[1;33mrun-state-machine-wrapped[m  [32m             ioc_macros.clj:  982[m
                 [33mclojure.core.async.impl.ioc-macros/[1;33mrun-state-machine[m  [32m             ioc_macros.clj:  978[m
             [33mclojure-lsp.handlers/initialize/fn/[1;33mstate-machine--auto--[m  [32m               handlers.clj:  115[m
          [33mclojure-lsp.handlers/initialize/fn/state-machine--auto--/[1;33mfn[m  [32m               handlers.clj:  116[m
    [33mclojure-lsp.feature.java-interop/[1;33mretrieve-jdk-source-and-analyze![m  [32m           java_interop.clj:  189[m
                                                    [33mbabashka.fs/[1;33munzip[m  [32m                    fs.cljc:  876[m
                                   [37mjava.nio.file.Files.newInputStream[m  [32m                 Files.java:  156[m
                  [37mjava.nio.file.spi.FileSystemProvider.newInputStream[m  [32m    FileSystemProvider.java:  420[m
                                   [37mjava.nio.file.Files.newByteChannel[m  [32m                 Files.java:  422[m
                                   [37mjava.nio.file.Files.newByteChannel[m  [32m                 Files.java:  371[m
                     [37msun.nio.fs.UnixFileSystemProvider.newByteChannel[m  [32mUnixFileSystemProvider.java:  219[m
[1;31mjava.nio.file.NoSuchFileException[m: [3m/home/delboni/Workspaces/180s/sarue/https:/raw.githubusercontent.com/clojure-lsp/jdk-source/main/openjdk-19/reduced/source.zip[m

rafaeldelboni17:04:30

Do I need to download the sdk manually?

rafaeldelboni17:04:56

I'm using nvim with nvim-lspconfig

ericdallo17:04:06

@UMMMKKADU I made a hotfix release, what's your version?

rafaeldelboni17:04:23

Oh sorry I forgot that info

rafaeldelboni17:04:38

clojure-lsp --version
clojure-lsp 2022.03.31-20.00.20
clj-kondo 2022.03.10-SNAPSHOT

ericdallo17:04:40

:thinking_face: @U04V15CAJ was having the same issue

ericdallo18:04:52

@UMMMKKADU please open a issue, I'm working on that code right now refactoring and improving testability, that should help understand this case too, meawhile, setting :java :jdk-source-uri manually or :java :download-jdk-source? to true should fix it

borkdude18:04:12

or set JAVA_HOME (your editor should be able to see that env var)

👍 1
borkdude18:04:11

@ericdallo perhaps the config should have :java-home where you can just put the same string as the env var

borkdude18:04:24

That would take care of any editor config issues

ericdallo18:04:45

you mean {:java {:home "JAVA_HOME"}} ?

ericdallo18:04:09

oh, {:java {:home "/path/to/home"}} ?

ericdallo18:04:29

I see, just a way to make easier than specifying :java :jdk-source-uri right? we would need to handle the java home specified not having the src.zip too, but makes sense

rafaeldelboni18:04:14

I will try to set the java home

snoe18:04:49

I thought this was a bug; so it might be helpful to vim users. When DiagnosticTag was added to clojure-lsp diagnostics, coc.nvim stopped underlining warnings, however I didn't see the fade out color being applied so I thought it was just broken. This fixed it for me in my nvim config. hi CocFadeOut gui=underline cterm=underline

👍 1
snoe18:04:41

@U0EHU1800 your post helped me track this down, maybe it's a similar issue in your emacs/terminal that doesn't properly show "faded" text.

ericdallo18:04:32

Thanks @U0BUV7XSA! Emacs has no fade concept, it's a gray color under the hood, so I'm not sure it's related with @U0EHU1800 issue

snoe18:04:33

yeah I suspect a plugin or theme I have changed the default, presumably grey highlight to nothing.

apt18:04:48

Hi folks. It seems that clojure-lsp sometimes does not suggest requiring a namespace with the alias I just wrote for it. For example, I wrote

(controllers.service.kafka/consumers service http)
this ns is not required yet, so I get the code action for fixing that. However, the suggested name is just kafka. Is that expected?

ericdallo18:04:49

we suggest the last segment kafka since the ns was never required

ericdallo18:04:14

what did you expect to happen @U976F1AR2?

apt18:04:32

I expected it to suggest controllers.service.kafka, since that’s what I manually typed

ericdallo18:04:44

yeah, we changed that behavior recently, and discussed it https://github.com/clojure-lsp/clojure-lsp/pull/877

ericdallo18:04:30

before that we indeed suggest import that ns as you were expecting, and I'm kind of agree that would be still a useful behavior, WDYT @U0BUV7XSA?

apt18:04:33

Got it. Well, defaults are hard. I don’t have strong opinions on this, but if it was configurable, I’d use the old behaviour.

ericdallo18:04:56

@U0BUV7XSA The issue is that people type the desired alias and want to require like that, which makes sense to me, so suggesting the type alias looks better than infer a last segment as the alias

snoe18:04:31

yeah, as we discussed either you bombard with all the options or you make some people unhappy.

snoe18:04:19

Maybe adding the rename-alias just makes recovery from a bad default much easier to live with

ericdallo18:04:25

yeah, a valid workaround, but the correct alias sounds better, I still don't see a issue with multiple alias suggestions, one thing I thought was to allow multiple alias suggestion but for project ns only

1
ericdallo18:04:41

so that would reduce a lot the possible suggestions

snoe18:04:10

What you're suggesting here is in the linked issue, change #4 to use the given alias.

snoe18:04:29

hrm... actually I would expect this to hit #2 and work as apt expected.

apt18:04:22

$ clojure-lsp --version
clojure-lsp 2022.03.26-18.47.08
clj-kondo 2022.03.10-SNAPSHOT
I’m sure this is not up to date, maybe that’s the reason

ericdallo18:04:29

yes, seems like it should git #2

ericdallo18:04:52

It's up to date @U976F1AR2 to that change at least

snoe18:04:02

@U976F1AR2 do you have it required as kafka elsewhere in the project? that would override that logic

apt18:04:25

I think I hadn’t at that point, I had just created the namespace (but not required it anywhere)

snoe18:04:08

k, I'd say this smells like a bug then.

👍 1
ericdallo18:04:36

@U976F1AR2 could you please create a issue with the detailed steps to repro the issue?

apt18:04:21

Cool, I’ll try to create a minimum repro recipe. Thanks, folks

🙏 2
snoe19:04:21

I wanted to highlight a test-helper functions on master for writing clojure-lsp tests changes-by-uri->code and changes->code. If you are trying to test something that does multiple code changes in a file (multiple {:loc .. :range ...} results), these functions will apply all of them to your test file in the same way as lsp clients should. cc @ericdallo @jacob.maine

ericdallo19:04:06

Yeah, really handy!

ericdallo19:04:32

we should probably refactor transform_test to use more this one

👍 1
jacob.maine19:04:54

Cool! I once had a vision of a whole testing DSL built around a mock editor

(let [e (-> (editor)
            (open-buffer "a.clj")
            (cursor-to 3 33)
            (open-action-menu)
            (choose-action "Move to let"))]
  (is (= [2 22] (cursor (current-buffer e))))
  (is (= "(let [a 1] (inc a))" (code-at-cursor (current-buffer e)))))
It would keep track of file contents and apply changes. It’d know where the cursor was, and what you saw when you opened the action menu

ericdallo19:04:55

that would be a awesome integration test, we have something similar, but more low level ATM with bb

jacob.maine19:04:31

Even that DSL is too low-level. Better would be to abstract away cursor positions:

(let [e (-> (editor)
            (open-empty-buffer)
            (insert-and-move "(inc |1)")
            (open-action-menu)
            (choose-action "Move to let"))]
  (is (= "(let [new-binding 1] (inc |new-binding))"
         (seeing (current-buffer e)))))

💯 1
jacob.maine19:04:45

Yeah… someday 🙂

🙏 1
borkdude19:04:59

A hackerdyhack script to get the clj-kondo github sha given a clojure-lsp version:

$ bb -e "(babashka.deps/add-deps '{:deps {com.github.clojure-lsp/clojure-lsp {:mvn/version \"2022.03.31-20.00.20\"}}})" -e "(require '[ :as io])" -e '(def xml (slurp (io/resource "META-INF/maven/clj-kondo/clj-kondo/pom.xml")))' -e '(second (re-find #"<tag>(.*)</tag>" xml))'

;;=> "3973aedec333ef5d773bf6446f36abf8a47cec96"

metal 1
KevinK23:04:24

re goto java classes feature, are there any thoughts of extending to clojurescript / javascript sources? I’d think it could be implemented in such a way as to allow extensibility. e.g. have kondo analysis get you to the edge and have a pluggable analysis for the interop language

KevinK23:04:36

sorry I didn’t follow the implementation too closely, but I’d be really interested in making this happen for clojurescript & plugging into some typscript/flow.js analysis. It’s THE biggest hindrance to my productivity in clojurescript.

ericdallo23:04:10

Yes, me and @U04V15CAJ talked little bit about it, it should be possible a similar work as we did for java analysis

ericdallo23:04:08

I think we can start with an issue @U01H0QSTUL9 explaining with the most details as possible how you would think clojure-lsp should behave so we can discuss and think on thepossibilities

1
grzm17:04:08

So, I think I might have figured out what is going on with clojure-lsp not working (but not why it was working before and stopped working): the source paths in my monorepo weren’t being picked up by clojure-lsp. I’m now creating a separate lsp “project” in each of the modules in the monorepo. The primary tool that helped me figure this out was looking at the output of lsp-clojure-server-info Also, ensuring I have :source-aliases set appropriately to include source paths from aliases other than :dev and :test.