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 https://clojure-lsp.io/features/#execute-command 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

https://github.com/clojure-emacs/clj-refactor.el/blob/master/examples/cljr-sr-refer-all.gif similar to stop-referring

@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

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.

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

Example:

Details are https://clojure-lsp.io/features/#diagnostics-linter, but the TLDR is:

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 https://clojure-lsp.io/features/#clojure-lspunused-public-var

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

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: https://clojure-lsp.io/troubleshooting/#client-server-log

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

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

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)

@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"}} ?

the second

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

https://github.com/clojure-lsp/clojure-lsp/issues/901

I will try to set the java home

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

c/c @U0BUV7XSA

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 https://github.com/clojure-lsp/clojure-lsp/pull/877

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

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.

@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

Yeah, really handy!

we should probably refactor transform_test to use more this one

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

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

Yeah… someday 🙂

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