Fork me on GitHub

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

omg, just wanted to ask the same question!


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


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


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


mm then it should be definitively auto fixable I guess


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


yeah refer would be enough


but how do you do it? I checked on but can't see the right way


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


but yeah would be nice to know


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


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


@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


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


cljr has a lot of hidden gems


@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

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


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

👍 1

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


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


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).


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


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.


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”


• 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


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


so the problem could be other


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


could you test it?


if no warnings, you have something misconfigured


probably in your emacs


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.


those are too clj-kondo findings


That linter is called unused-binding


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?


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


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


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


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


via .clj-kondo/config.edn


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)


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


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.


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


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)


clojure-lsp --version reports:


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


and likewise, manually running clj-kondo finds linting issues


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


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


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.


you can start checking client<->server log to see if clojure-lsp is working good and returning diagnostics:


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.


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.


@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


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


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


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


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


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.


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


2022-04-01T13:32:50.212Z  INFO [] - [93m[Java][0m Local JDK source not found.
2022-04-01T13:32:50.212Z  INFO [] - [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
[[m  [32m  194[m
            [[m  [32m   597[m
                                                 [[m  [32m        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$[m  [32m  628[m
                    [37mjava.util.concurrent.ThreadPoolExecutor.runWorker[m  [32m 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
    [[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         156[m
                  [37mjava.nio.file.spi.FileSystemProvider.newInputStream[m  [32m  420[m
                                   [37mjava.nio.file.Files.newByteChannel[m  [32m         422[m
                                   [37mjava.nio.file.Files.newByteChannel[m  [32m         371[m
                     [37msun.nio.fs.UnixFileSystemProvider.newByteChannel[m  [  219[m
[1;31mjava.nio.file.NoSuchFileException[m: [3m/home/delboni/Workspaces/180s/sarue/https:/[m


Do I need to download the sdk manually?


I'm using nvim with nvim-lspconfig


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


Oh sorry I forgot that info


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


:thinking_face: @U04V15CAJ was having the same issue


@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


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

👍 1

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


That would take care of any editor config issues


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


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


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 too, but makes sense


I will try to set the java home


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

@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.


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


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


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?


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


what did you expect to happen @U976F1AR2?


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


yeah, we changed that behavior recently, and discussed it


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?


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.


@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


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


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


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


so that would reduce a lot the possible suggestions


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


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


$ 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


yes, seems like it should git #2


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


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


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


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

👍 1

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


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

🙏 2

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


Yeah, really handy!


we should probably refactor transform_test to use more this one

👍 1

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)
            (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


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


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

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

💯 1

Yeah… someday 🙂

🙏 1

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

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


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.


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


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


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.