Clojurians Log v2

Yep using lsp mode -- Thanks Eric!

Is potemkin/import-vars supported by LSP? should it work by default or do I need to add something to my config? My understanding (perhaps mistaken) is that the newest clojure-lsp uses clj-kondo for analyzing references (and clj-kondo does support import-vars). Wondering if I'm missing something or if this just isn't supported right now.

@pithyless clj-kondo has some support for it, but it might not be support fully yet with respect to analysis output which LSP uses. I'm wondering what your issue is?

In ns1 I've got a (import-var other-ns foo) ; and in ns2 I'm seeing unresolved-var warning when calling (ns1/foo)

@pithyless that's a clj-kondo issue: https://github.com/clj-kondo/clj-kondo/issues/1167

the unresolved var linter is a new one which doesn't read all the necessary namespaces when it comes to potemkin, this needs a custom fix for potemkin

it does work when you lint all the namespaces in one go.

a workaround for now is to exclude the namespace in which you import the vars from the unresolved-var linter

🙏 thanks! I was going a little crazy testing different permutations (first time setting up lsp with doom-emacs).

> it does work when you lint all the namespaces in one go. This has been my experience when running clj-kondo. I suppose that means flycheck (that also uses clj-kondo) was running the linter differently?

no, you should see the same problem when running with flycheck I think

I still run my diagnostics using flycheck, not lsp, although I do use lsp

(it almost sounds like a drug, does it)

@borkdude I disabled lsp and enabled flycheck and can confirm that it correctly parses vars generated by import-vars; (running doom-emacs).

^ dammit, PEBKAC. I take it back.

it looks like my flycheck config was simply not checking for unresolved-vars in other NSes

you were probably running a not-up-to-date clj-kondo since this check is only there since the latest release (last month)

of course you can turn it off completely if you want

yeah, and I think I was relying on a cider and/or clj-refactor feature (for lsp I've been testing w/o any connected repl)

one question is: when you navigate to a potemkin-imported var, should you go to the importing namespace or the imported namespace (the real definition)?

I think both of those answers can be considered "correct". I'd be less surprised to go to the importing NS; and from there be able to jump again to the real definitions.

Due to all the tooling quirks and potential issues with AOT, etc. I'm well aware of the questions raised by even using potemkin (especially since I'm wrapping it with my own custom macro that supports CLJC). But I really like the idea of separating implementation NSes from the public API and wish there was a less frowned upon approach to doing this.

I've even considered just doing the busy work of copy-pasting the functions and macros - and calling out to the originals; but should I also copy the docstrings; etc?

What I sometimes do is use a function which just generates the code for doing this and then pasting this code in the file. This has the benefit that the tooling gets it ;)

One recent example of this is https://github.com/babashka/babashka/blob/e4a96606703a1c6f3bf5177270cd5131b24a2b44/src/babashka/impl/fs.clj#L10-L16 which updates the code below between the ;; placeholder comments.

and I can actually see what's going on

I've been thinking of how to generalize this approach: macros/fns which update a dedicated segment in the file just below the invocation

It might also be considered hacky, just fwiw ;)

Thanks, I think it may be a good tradeoff 🙂

you could do this by just copying the docstring meta from the original vars and then writing them to the target "API" namespace

@pithyless added @borkdude suggestion to workaround this for lsp users: https://github.com/clj-kondo/clj-kondo/issues/1167#issuecomment-777413482

@pithyless I am also currently doing a cljc import-vars for rewrite-clj v1. I personally like the concept in theory, but the practical costs are certainly questionable.

:clojure-lsp: Released https://github.com/clojure-lsp/clojure-lsp/releases/tag/2021.02.11-12.43.06 🎉 : • Fix auto add new ns to new blank files • Add new code action: Move expression to let • Add new code action: Change collection to map, vector, list, set

This is awesome!

Thank you 😄

Do you also tweet these things? I want to retweet them ;)

hahahah I don't have a twitter (yeah, I know :man-facepalming:too many social apps 😛 )

but feel free to tweet them 😄

I will do it for you then

https://twitter.com/borkdude/status/1359862616445886467

Thank you ❤️

How do I activate changing the coll type btw? I am trying cycle-coll, is that the right one?

when cycling from [1 2 3] to {1 2 3} you get into an invalid state btw

which you cannot cycle out of

oh, it's a new one change-coll , but we already return it as a code action, so you can just lsp-execute-code-action and choose that

oh nice, thanks

Also, lsp-mode show the code actions info in two possible ways: • via modeline https://emacs-lsp.github.io/lsp-mode/page/main-features/#code-actions-on-modeline • via lsp-ui (maybe too much): https://emacs-lsp.github.io/lsp-ui/#lsp-ui-sideline Personally I just enable the modeline one which is simple and works nice

(it's enabled by default AFAIK in lsp-mode)

oh I never paid attention to that, thanks. I think I'll just use M-x though

Hmmm

which is more keystrokes than making the actual change myself ;)

Just trying it out, and there' weirdness with Vim going on

How do you record screens so I can show?

I use https://github.com/phw/peek

kk

righty, let's try this...

oh, that's odd, let me try in emacs

it works in emacs 😕

you hear it, you should switch to emacs then

Errrrrr....no 😛

@dharrigan to debug that you can check what the vim client is sending as the position params

Just doing that

waaay ahead of you 🙂

[Trace - 14:27:39] Sending request 'workspace/executeCommand - (3)'.
Params: {
    "command": "change-coll",
    "arguments": [
        "file:///home/david/foo.clj",
        0,
        0,
        "set"
    ]
}

line 0, position 0

Looks wrong to me

@dharrigan Can you try again with the cursor exactly on the first character of the coll?

Yeah, ☝️ line 0, col 0 is really wrong

same

let's try inside

same

Could you confirm other code actions/refactor commands send correct position?

okay, let's try rename

oh, check the code action that is being returned from server, where reurn the position to client send on that request

@lee @pithyless thinking more about this, seeing what's in the latest release, maybe "create API namespace" could even be an LSP code action

hmm, that's not working now either

rename isn't renaming

try a restart?

Playing around...

Probably a bug introduced on coc ?

:thinking_face: I don't get it, what should this action do exactly?

a ns for an API that uses potemkin?

This would replace potemkin by just generating the code: copying the docstrings of the other var and just proxying the args to the other var

Just an import-var action could also work

This is probably something that should need some hammock time

oh, seems helpful but probably a huge action

but yeah, I would like to add those kind of actions, it'd be even better to use kondo analysis to know if user has potemkin and suggest that kind of action

The information is basically already there in the kondo analysis

no, a user would NOT use potemkin anymore

this is what we would like to get rid off

oh yeah, got it, I was just wondering when show that action so

So when you say: import-var foo/bar, you generate a function:

(defn bar "<docstring>" [x]
  (foo/bar x))

what is the requirement to show that? like ,for change coll, we only return that action when cursor is in a coll

yeah, that's probably not hard

we already have all that info

kondo is our life saver 😛

Maybe show it when the user types foo/bar and hovers this?

This would make clj-kondo's life easier as well

and this would work for both CLJ and CLJS

yeah, it makes sense, a detailed repro would be really helpful though

[Trace - 14:46:51] Sending request 'textDocument/rename - (37)'.
Params: {
    "textDocument": {
        "uri": "file:///home/david/foo.clj"
    },
    "position": {
        "line": 6,
        "character": 6
    },
    "newName": "foos"
}


[Trace - 14:46:51] Received response 'textDocument/rename - (37)' in 1ms.
No result returned.

Why would clojure-lsp not honour a rename request?

rename request is a different thing

is not a workspace/executeCommand

I am thinking of maybe leaving my import-vars in my code but wrapping it in an #_ and then have a build step see that and insert/update generated shims. I have a variant of import-vars that also renames.

I think the bug will happen for every workspace/executeCommand (move-to-let, clean-ns, cycle-coll, introduce-let, inline-symbol, etc)

Wow this is amazing (well, except for the part that doesn't work but that is a smail detail 😅), how do you get that menu?

import-vars as a lsp action sounds like a great compromise; although I would suggest generating code using meta arglists syntax (better support for custom macros and multiple cardinality). Renaming would also be easy - someone could literally just change the new var after the action and leave the rest of the code unchanged.

Only diff from potemkin and @lee’s approach is that an lsp action is a one-time event (docstring etc won’t update automatically).

yeah, I'm thinking of some action I've got in VSCode markdown where you can update a table.

so you could also have update-imported-var

OTOH, if you’d like to change something (docstring, additional cardinality, pre/post assertions, etc) you’ve got easy to work with code and no need to expand some macro or build step with new functionality

or update-imported-vars

maybe the imported var could have some metadata or annotation (like clj-kondo's #_:clj-kondo/ignore to signal that it was imported and can potentially be synced

yeah, a marker would make sense if resync is of interest

it's almost just like a template

foo.bar.api.template.clj and then fill in the blanks

hmmm... template idea does seem simpler than updating in place.

for me, I’ll be importing without change (well except for my renames at import time), but @pithyless does have the use case of importing then changing.

Should clojure-lsp be running clj-kondo on startup?

to analyse the file(s)?

yes, but it uses clj-kondo via JVM API

Why?

I'm getting this

02-11T15:14:06.753Z daffy WARN [clojure-lsp.db:45] - Could not load db path to '/home/david/tmp/foo/.lsp/sqlite.db': '/home/david/tmp/foo/.lsp' does not exist
2021-02-11T15:14:06.754Z daffy INFO [clojure-lsp.crawler:138] - Paths analyzed, took 0.001144411 secs. Caching for next startups...
2021-02-11T15:14:06.757Z daffy INFO [clojure-lsp.main:342] - Initialized
2021-02-11T15:14:30.932Z daffy INFO [clojure-lsp.main:396] - Starting server...
2021-02-11T15:14:30.935Z daffy DEBUG [clojure-lsp.nrepl:24] - nrepl not found, skipping nrepl server start...
2021-02-11T15:14:30.938Z daffy INFO [clojure-lsp.main:303] - Initializing...
2021-02-11T15:14:31.027Z daffy WARN [clojure-lsp.db:45] - Could not load db [SQLITE_ERROR] SQL error or missing database (no such table: project)
2021-02-11T15:14:31.028Z daffy INFO [clojure-lsp.crawler:138] - Paths analyzed, took 0.001078665 secs. Caching for next startups...
2021-02-11T15:14:31.031Z daffy INFO [clojure-lsp.main:342] - Initialized
2021-02-11T15:15:27.645Z daffy INFO [clojure-lsp.main:396] - Starting server...
2021-02-11T15:15:27.648Z daffy DEBUG [clojure-lsp.nrepl:24] - nrepl not found, skipping nrepl server start...
2021-02-11T15:15:27.652Z daffy INFO [clojure-lsp.main:303] - Initializing...
2021-02-11T15:15:27.742Z daffy WARN [clojure-lsp.db:45] - Could not load db [SQLITE_ERROR] SQL error or missing database (no such table: project)
2021-02-11T15:15:27.743Z daffy INFO [clojure-lsp.crawler:138] - Paths analyzed, took 0.001129293 secs. Caching for next startups...
2021-02-11T15:15:27.746Z daffy INFO [clojure-lsp.main:342] - Initialized

so I created the .lsp directory

and the sqlite.db is 0 bytes in size

I'm still trying to figure out why it's not doing the cocaction and the rename

it should create the dir and the file when starting, and only after all analyzer it should add to the file

nope

it's not creating the dir

interesting

:thinking_face: it creates for me

it's clojure-lsp responsibility to create that

All I can report is what I see

❯ rm /tmp/clojure-lsp.out && tail -F /tmp/clojure-lsp.out
tail: cannot open '/tmp/clojure-lsp.out' for reading: No such file or directory
tail: '/tmp/clojure-lsp.out' has appeared;  following new file
2021-02-11T15:19:54.091Z daffy INFO [clojure-lsp.main:396] - Starting server...
2021-02-11T15:19:54.093Z daffy DEBUG [clojure-lsp.nrepl:24] - nrepl not found, skipping nrepl server start...
2021-02-11T15:19:54.097Z daffy INFO [clojure-lsp.main:303] - Initializing...
2021-02-11T15:19:54.107Z daffy WARN [clojure-lsp.db:45] - Could not load db path to '/home/david/bob/foo/.lsp/sqlite.db': '/home/david/bob/foo/.lsp' does not exist
2021-02-11T15:19:54.109Z daffy INFO [clojure-lsp.crawler:138] - Paths analyzed, took 0.001491572 secs. Caching for next startups...
2021-02-11T15:19:54.112Z daffy INFO [clojure-lsp.main:342] - Initialized

  ~/bob/foo                                                                                                                                                                                                                                                 
❯ ls -la
total 12
drwxr-xr-x 2 david david 4096 Feb 11 15:19 .
drwxr-xr-x 3 david david 4096 Feb 11 15:19 ..
-rw-r--r-- 1 david david   36 Feb 11 15:19 foo.clj

no .lsp directory

Another issue too

2021-02-11T15:23:30.027Z daffy ERROR [clojure-lsp.main:?] - 
com.oracle.svm.core.posix.thread.PosixJavaThreads.pthreadStartRoutine      PosixJavaThreads.java:  192
            com.oracle.svm.core.thread.JavaThreads.threadStartRoutine           JavaThreads.java:  519
                        java.util.concurrent.ForkJoinWorkerThread.run  ForkJoinWorkerThread.java:  183
                          java.util.concurrent.ForkJoinPool.runWorker          ForkJoinPool.java: 1594
                               java.util.concurrent.ForkJoinPool.scan          ForkJoinPool.java: 1656
             java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec          ForkJoinPool.java: 1020
                             java.util.concurrent.ForkJoinTask.doExec          ForkJoinTask.java:  290
              java.util.concurrent.CompletableFuture$AsyncSupply.exec     CompletableFuture.java: 1692
               java.util.concurrent.CompletableFuture$AsyncSupply.run     CompletableFuture.java: 1700
                    clojure-lsp.main.LSPTextDocumentService/reify/get                   main.clj:  150
                                      clojure-lsp.handlers/completion               handlers.clj:  107
                            clojure-lsp.feature.completion/completion             completion.clj:  203
                                               clojure.core/namespace                   core.clj: 1599
java.lang.ClassCastException: java.lang.Long cannot be cast to clojure.lang.Named

I have this mapping

nmap <silent> <Leader>act <Plug>(coc-codeaction)

It would be interesting to know if it works for you

That issue with completion is a bug, please open a issue related to that with some repro check the process stderr too about, it's odd that is not creating the .lsp dir

I’m interested mainly in importing once; it’s also nice to serve as a template that I can rename or change afterwards. I just wanted to mention this is different than how potemkin works now, since others may be dependent on the sync behavior.

It sort of works but it's only showing clean namespace

Oh, there is an update on clojure-lsp (I'm on arch linux, so thank you for maintaining lots of clojure related packages!)

Let me try after the update.

I tested it and for me after removing the .lsp folder, it creates it correctly after the startup log:

2021-02-11T15:32:39.261Z gregnix-nubank INFO [clojure-lsp.main:396] - Starting server...                                                                                                      
2021-02-11T15:32:39.399Z gregnix-nubank DEBUG [clojure-lsp.nrepl:24] - nrepl not found, skipping nrepl server start...                                                                        
2021-02-11T15:32:39.439Z gregnix-nubank INFO [clojure-lsp.main:303] - Initializing...                                                                                                         
2021-02-11T15:32:39.568Z gregnix-nubank WARN [clojure-lsp.db:45] - Could not load db path to '/home/greg/dev/clojure-lsp/.lsp/sqlite.db': '/home/greg/dev/clojure-lsp/.lsp' does not exist    
2021-02-11T15:32:41.086Z gregnix-nubank INFO [clojure-lsp.crawler:87] - Analyzing 125 paths with clj-kondo with batch size of 3 ...                                                           
2021-02-11T15:32:41.087Z gregnix-nubank INFO [clojure-lsp.crawler:93] - Analyzing 1/3 batch paths with clj-kondo...                                                                           
2021-02-11T15:32:49.678Z gregnix-nubank INFO [clojure-lsp.crawler:93] - Analyzing 2/3 batch paths with clj-kondo...                                                                           
2021-02-11T15:33:01.747Z gregnix-nubank INFO [clojure-lsp.crawler:93] - Analyzing 3/3 batch paths with clj-kondo...                                                                           
2021-02-11T15:33:02.846Z gregnix-nubank INFO [clojure-lsp.crawler:138] - Paths analyzed, took 21.760649 secs. Caching for next startups...                                                    
2021-02-11T15:33:03.182Z gregnix-nubank INFO [clojure-lsp.crawler:167] - Manual GC after classpath scan took 0.11262293 seconds
2021-02-11T15:33:05.913Z gregnix-nubank INFO [clojure-lsp.crawler:138] - Paths analyzed, took 1.1907887 secs. Caching for next startups...

Seem to be fine with the built in nvim lsp

Did you try with a single file?

I mean a directory with only one clj file in it?

oh, that's the reason

For I can reproduce this every time, but with one of my projects with hundreds of iles, it creates the .lsp directory and sqlite db

That and an empty deps.edn

we don't persist okndo analysis for non projects, since we don't have a project root

when the project has a deps/project/boot file, it's considered a project on most clients

but a single clojure file in afolder it is not

would that affect the cocactions?

So I can see the change collection but got the same result as you, it changes the ns declaration.

only the add-missing-* probably

hmm, okay, then I'm still at a mystery of why cocactions doesn' work. I probably need another independent source to verify

just tested a single /tmp/clojure-test.clj file and the code actions works as expected

but on emacs?

also the .lsp folder is not created as expected as well

not vim

yes

yeah, I need a vim source 🙂

Maybe @rafaeldelboni can test it too?

Ah

Someone else verified it

https://clojurians.slack.com/archives/CPABC1H61/p1613057819023400?thread_ts=1613052658.477000&cid=CPABC1H61

Thank you

So, <shrug> something broken somewhere

yeah, I'll double check clojure-lsp side, but probably a vim client bug

would be helpful if you could provide the lsp logs of the return of textDocument/codeActions

where shows all available code actions (and the data field, that's what I want)

kk, I'll raise a bug on this, even though I completely understand it may not be a clojure-lsp issue

but hard to track here on slack

kk

About the .lsp folder?

no, that's been solved

🙂

it's about the coc-codeactions

just filing a bug right now

I have the same behavior as you

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

thanks!

we'll get to the bottom of this for sure! 🙂

oh yeah… forgot… my import-vars variant can also modify docstrings… I might just go ahead and experiment with the template idea…

@dharrigan how you enable debug to show the coc commands in the logs?

I have this is my settting:

<https://the.wepl.blog/>

this? "trace.server": "verbose",

then I do, in vim :CocCommand workspace.showOutput

Yes

> Move expression to let Works really nice; but for some reason I can't get LSP rename to work (either on a let binding or top-level var). I get a popup Rename foo to: ... but after changing the name and hitting enter - nothing happens. I also don't see anything relevant in *lsp-log* or *clojure-lsp*; any suggestions on how to debug this in emacs?

could you check /tmp/clojure-lsp.out?

any exception or any log on that file after you try to rename?

How is responsible to build the action menu? The menu is arriving wrong here with line and column zero

DEBUG [clojure-lsp.main:?] - :documentHighlight 0 clojure.lang.LazySeq@58bd0ac2
DEBUG [clojure-lsp.main:?] - :hover 0 clojure.lang.LazySeq@2a49da2b
DEBUG [clojure-lsp.main:?] - :documentHighlight 0 clojure.lang.LazySeq@2a9574c7
DEBUG [clojure-lsp.main:?] - :documentHighlight 0 clojure.lang.LazySeq@eb12ea9f
DEBUG [clojure-lsp.main:?] - :hover 0 clojure.lang.LazySeq@4eddda28

doesn't look like it

Oh I just saw the comments in the issue, sorry

yeah, what are you trying to rename?

(defn foo []
  (let [a (+ 3 3)
        new-binding (+ 3 3 4)]
    new-binding))

yeah, it should work, what clojure-lsp version are you using?

clojure-lsp --version

clojure-lsp 2021.02.11-12.43.06

@ericdallo can I easily repro the case via the CLI? (to rule out the clojure-lsp?)

GNU Emacs 27.1 (build 1, x86_64-apple-darwin18.7.0, NS appkit-1671.60 Version 10.14.6 (Build 18G6042)) of 2021-02-08

ATM there is no way to use clojure-lsp via terminal 😅

oh, make sure you have a updated lsp-mode

turns out lsp-mode was up-to-date, but I did end up bumping all my doom packages 😅

either way, no dice

that's weird, you can open a issue on clojure-lsp with a repro and more information

Should clojure-lsp support autocompletion for only the clojure.core functions or also function :require'd into the namespace?

Currently setting up and environment with neovim 0.5 lsp, https://github.com/nvim-lua/completion-nvim and clojure-lsp and don't seem to get any other autocompletes than those

it should work for both @matias287 , but we still have a issue when completing non valid clojure code

Check here for more info: https://github.com/clojure-lsp/clojure-lsp/issues/270

Cheers. I'll check it out

My current situtation is that core gets filled:

But others don't

But yeah nice to see it's already under discussion 🙂

change collection is also available in emacs clojure mode. would be interesting exercise to compare clj and elisp impl

str/sp should work like it works for emacs

Hmm that's weird

I wonder why it's not displaying it with nvim

can you check your /tmp/clojure-lsp.out if there is any exception or something rellevant

Yeah, since clojure-lsp is a server this feature could be used in Calva VSCode and vim for example

for emacs users, they could choose one or other or just trust on lsp code actions and forget about the cycle colls keybindings from clojure-mode 😄

yup ofc i am aware this impl pushes this feature up for a wider audience. that is cool ofc

🙇

It doesn't seem to print anything when I write (string/spl) but it does output this when I'm writing the string part of a simple (println "hello world")

2021-02-11T19:59:34.608Z Rainfall ERROR [clojure-lsp.main:?] -
com.oracle.svm.core.posix.thread.PosixJavaThreads.pthreadStartRoutine      PosixJavaThreads.java:  192
            com.oracle.svm.core.thread.JavaThreads.threadStartRoutine           JavaThreads.java:  519
                        java.util.concurrent.ForkJoinWorkerThread.run  ForkJoinWorkerThread.java:  183
                          java.util.concurrent.ForkJoinPool.runWorker          ForkJoinPool.java: 1594
                               java.util.concurrent.ForkJoinPool.scan          ForkJoinPool.java: 1656
             java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec          ForkJoinPool.java: 1020
                             java.util.concurrent.ForkJoinTask.doExec          ForkJoinTask.java:  290
              java.util.concurrent.CompletableFuture$AsyncSupply.exec     CompletableFuture.java: 1692
               java.util.concurrent.CompletableFuture$AsyncSupply.run     CompletableFuture.java: 1700
                    clojure-lsp.main.LSPTextDocumentService/reify/get                   main.clj:  150
                                      clojure-lsp.handlers/completion               handlers.clj:  107
                            clojure-lsp.feature.completion/completion             completion.clj:  203
                                               clojure.core/namespace                   core.clj: 1599
java.lang.ClassCastException: java.lang.String cannot be cast to clojure.lang.Named

😉

This is other issue fixed on next release: https://github.com/clojure-lsp/clojure-lsp/issues/310

Ahh gotchu. But yeah, no output into the file on the string/sp part.

Alright, so to debug this we would need info about lsp request reponse

Could you please open a issue following the bug report? then we can track the issue

Sure!

Should the autocomplete kick in at this point too? Offering snippets like clojure.string etc? If so, should I write that into the same ticket?

We don't have this feature yet, but it's a nice enhancement 🙂

You should open a different one, a feature request

Sure thing! 🙂

Is it normal for lsp/kondo to complain about (:require [clojure.test :refer :all]) ? I write all my tests this way so it would be nice to deactivate that complaint ... or even nicer if lsp/kondo understood that use-fixtures, deftest, and testing are all definitely resolved symbols.

@steven427 You can turn this off, but clj-kondo might have trouble resolving those vars to the correct namespace if you have multiple :refer :alls

See https://github.com/borkdude/clj-kondo/blob/master/doc/linters.md for more details.

E.g. this works without problems:

(require '[clojure.test :refer :all])

use-fixtures

(deftest foo (testing (is 1)))

(or at least on my machine)

clojure.test should be the only :refer :all ever, I think.

You can configure this.

Am I configuring kondo to ignore it entirely? Or configuring it to parse :all correctly?

Configure it to don't trigger a warning for clojure.test

https://github.com/clj-kondo/clj-kondo/blob/master/doc/linters.md#refer-all

Ah, sorry. Just saw :refer-all ... haven't written Clojure in about 6 years and wasn't familiar with that. Switching to it doesn't seem to convince kondo/lsp that those symbols exist, though.

That should work. Can you make a tiny repro of your code?

E.g. the code that I pasted above works for me. Not for you?

Sure, let me try. lsp also isn't inserting missing requires it's suggesting, so it's possible my setup is misconfigured for ns-macro stuff.

Your 3 lines break for me as well, so I'm guessing it's something I've configured strangely. I'll poke around a bit.

If you can reproduce this with only clj-kondo e.g. using the binary on the command line, feel free to post an issue in the #clj-kondo or on Github. Else it might be something in LSP. I"m afk now ... 💤

Yeah, I don't think it's a issue, probably missing clj-kondo config

Sounds good. Thanks for the pointers.

This doesn't need a config, since clojure.test is built into clj-kondo.

@ericdallo Is there any assumption that I'd configure clj-kondo baked into an lsp-clojure install? Because I don't use clj-kondo otherwise and I have no custom configuration whatsoever. 🙂

The only case where this could go wrong is if you have linted a namespace named clojure.test which would have overwritten the analysis information that is built-in clj-kondo.

I'm quite certain I didn't do that but weirder things have happened.

so if you accidentally typed (ns clojure.test) this might have happened

it's kind of confusing to me what is your issue

@steven427 To be sure, you can wipe out .clj-kondo/.cache

I don't seem to have a .clj-kondo/.cache anywhere... should kondo or lsp have created it on my behalf?

if you are running clojure-lsp in a project, it should create in your-project/.clj-kondo/.cache

Hm, nope.

Are you sure you are even running clj-kondo and not another linter? Just checking...

(I've had this before)

Honestly, no idea. This is a pretty vanilla lsp-clojure install, save a few :custom settings.

Please follow the clojure-lsp Github new issue template to check everything is working, client-server logs, lsp logs, editor, version etc

(use-package lsp-mode
  :hook ((clojure-mode . lsp)
         (clojurec-mode . lsp)
         (clojurescript-mode . lsp))
  :config
  ;; add paths to your local installation of project mgmt tools, like lein
  (setenv "PATH" (concat "/usr/local/bin" path-separator (getenv "PATH")))
  (dolist (m '(clojure-mode
               clojurec-mode
               clojurescript-mode
               clojurex-mode))
    (add-to-list 'lsp-language-id-configuration `(,m . "clojure")))

  ;; Optional: In case `clojure-lsp` is not in your PATH
  (setq lsp-clojure-server-command '("bash" "-c" "clojure-lsp"))

  :custom
  (lsp-auto-guess-root t)
  (lsp-eldoc-enable-hover nil)
  (lsp-enable-file-watchers nil)
  (lsp-enable-folding nil)
  (lsp-headerline-breadcrumb-enable nil)
  (lsp-idle-delay .01)
  (lsp-keymap-prefix nil)
  (lsp-session-file (me/cache-concat "lsp/session.eld")))

(Sorry for the mess)

Thanks, I'll have a look

Oh, I can reproduce this when I enable lsp-diagnostics.

Oh.

So I guess @ericdallo can take it from here, I'll be asleep now. It's definitely an LSP related problem, can't reproduce with clj-kondo itself.

I'll try disabling lsp-diagnostics, I've also got flycheck turned on and I think I saw you mention above that they conflict.

thanks for the help @borkdude

lsp-diagnostics use flycheck

Not sure you should disable it unless you want to use clj-kondo linter manually or any other linter

so, for me this works:

(ns foo
  (:require [clojure.test :refer :all]))

deftest

(ns foo
  (require '[clojure.test :refer :all]))

deftest

This should also work:

(require '[clojure.test :refer :all]
         '[clojure.string :refer :all])

use-fixtures

but that's not the problem, it doesn't work in both cases

Hmm. I've got flycheck-clj-kondo enabled on clojure-mode ... will they conflict?

If you are using flycheck-clj-kondo you can turn off lsp-diagnostics

flycheck-clj-kondo will assume you have clj-kondo installed on your system

oh, both cases? yeah, looks odd, please open an issue with a repro @steven427

Is there a safe way to bounce the clojure-lsp server from within emacs on these sorts of config changes? Or should I just restart emacs so I know I'm starting with a clean slate, state-wise?

Okay

lsp-workspace-restart should be enough

Strange. @ericdallo Is there any value in testing a manual install of clj-kondo instead of letting clojure-lsp do it behind the scenes?

for debugging purposes, you can check if using only clj-kondo it works

if it works, then the issue may be in clojure-lsp

if not, is a clj-kondo config issue probably

Makes sense. Thanks.

locally I got:

$ clj-kondo --lint foo.clj
foo.clj:1:32: warning: use alias or :refer [deftest is testing use-fixtures]
foo.clj:2:34: warning: use alias or :refer [join]
linting took 99ms, errors: 0, warnings: 2

But I can't see why users should disable clojure-lsp linting and use clj-kondo manually (unless you are @borkdudeand always has a clj-kondo snapshot version 😆)

@borkdude probably related to the cache that lsp caches on startup?

I don't know where this cache is

it's from your-project/.clj-kondo/.cache

the behavior in your print happens to me too, but I thought it was expected

I don't have a .clj-kondo dir here

this file is /tmp/foo.clj

and I placed an empty deps.edn there too, just to make sure

please remove the quote

and make require :require

then it works as expected:

but not on my machine.

note: there is no .clj-kondo

just /tmp/foo.clj and /tmp/deps.edn (empty map)

let me test it on a tmp folder

also reproduces for me when I put it in ~/repro/foo.clj

it works:

here's my code:

(ns foo (:require [clojure.test :refer :all]
                  [clojure.string :refer :all]))

use-fixtures

(deftest foo (testing (is 1)))

join

/tmp/clojure-sample.clj

and you have no /tmp/.clj-kondo?

yep. no /tmp/.clj-kondo or /tmp/.lsp since is not a project

this is weird.

😕

I can reproduce exactly what Steven has, but only with LSP

Hm. Installing clj-kondo (using install-clj-kondo) and running it against my test dir produces the same results.

steven@solasa kosa % clj-kondo --version
clj-kondo v2021.01.20

More specifically, it gives me Unresolved symbol: deftest for :refer-all and warning: use alias or :refer [deftest is testing] for :refer :all.

@steven427 You should use :refer :all.

The linter is called :refer-all

You can configure the linter like here: https://github.com/clj-kondo/clj-kondo/blob/master/doc/linters.md

But :refer-all is not valid Clojure syntx

Oh. :woman-facepalming: Sorry. I was wondering why I didn't recognize it.

Nonetheless I get these warnings from LSP :/

It's way too later here, I'm off.

We can check that tomorrow, thanks @borkdude

Okay, that much at least is answered then. If I use --config '{:linters {:refer-all {:exclude [clojure.test]}}}' from the command line, clj-kondo has no complaints.

this should work for clojure-lsp too 🙂 You just need to add to your-project/.clj-kondo/config.edn

Yeah, I did... surprisingly, it still complains about both :all and the symbols. I'll try bouncing emacs.

sorry outdated one ☝️

Cool. It respects the proj/.clj-kondo/config.edn ignore of the :refer-all linter but it unfortunately still says the symbols (`deftest`, etc.) are undefined.

did you import the root of your project the first time started lsp-mode in your project?

I'm not sure what that question means

when you open a project with lsp-mode, it asks what is the root of your project

something like that:

Oh, I have lsp-mode hooked to clojure-mode