Clojurians Log v2

@ericdallo 2021.03.01-19.18.54 no longer shows the exception in the log but auto-completion still does not work when there’s a splicing reader conditional in the file

Not a big deal for me, just an FYI 🙂

I see, yeah, that probably would only be possible to fix with rewrite-cljc, we will need to wait for the v1 branch

I am I think having a similar issue maybe? In the same file, I see two function bodies. One follows the other:

(defn foo []
  (log/error ...))

(defn bar []
  (log/error ...))

I blew away .lsp/sqlite* and .clj-kondo/.cache.

no change

What's your clojure-lsp --version?

clojure-lsp 2021.02.24-14.23.08

BTW clj-kondo only warn the first unresolved symbol

Hum, odd, the same issue indeed

We didn't change that code recently(latest releases), Could you open a issue with a reprod of clj-kondo on command line working where clojure-lsp doesn't?

I mean, on the upside, it’s kind of a repro? I don’t have the smallest reproducible case, but I assume it won’t be too difficult.

sure

@ericdallo will include this in the report, but just FWIW: I did not update clj-kondo until after I saw this issue.

Clojure-lsp use a specific clj-kondo version(also show on clojure-lsp --version), not your clj-kondo installed

A minimal repro in a issue is a good start to start debugging the problem

of course I can’t get the minimal repro case to work in a fresh repo 🤦

ah, there it goes

That why I suggested removing the cache files, check if you have anything on your deps.edn that may cause that

A different alias for classpath or something

so, i am not sure if I am able to reliably reproduce

and it’s possible it has something to do with clj-kondo/config.edn’s existence? but it seems to come and go across restarts + clearing of the cache and sqlite db

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

updated with a repo where I can reliably reproduce

@ericdallo ^

@kommen If you happen to have a minute, https://github.com/clojure-lsp/clojure-lsp/issues/352 — can you reproduce by follow the repro steps in this issue?

It looks like if I remove my .clj-kondo directory (and by extension its config.edn), that fixes it.

anyway, updated the repro steps. please let me know if I can be of any help in testing. (DM generally works better)

Thank you! Too late here, but I'll look tomorrow morning

What is *clj for? (I found that filtering without this doesn't filter at all)

If I’ve integrated lsp in my editor, does kondo provide anything on top?

Clojure-LSP uses clj-kondo so you will get the same diagnostics (provided LSP calls clj-kondo correctly, there have been some problems)

That was my impression, thanks for confirming

Hm, homebrew reports that the latest version of clojure-lsp is still 2021.02.24-14.23.08

Eric Dallo told me yesterday that automagically updating the homebrew package failed. FWIW, I always do this manually for my packages.

You can download the binary manually from Github releases for now

Sounds like a pain to update homebrew manually, I feel for you...

Yeah I'm going to download the binary from Github, just wanted to let someone know. How amazing is that we have binaries for this, BTW...

@orestis Of course I have scripts for this, but it's a manual action which takes me about 10 seconds

This is relatively nothing compared to the time that goes into a developing the release

So, it's a clj-kondo issue, I'll add the details to the issue

@orestis I bumped clojure-lsp tap, you can now install latest via homebrew, I'll work on the auto bump soon

@kommen please check the issue above ☝️ it could be related with your issue indeed

@ericdallo thank you, confirmed this is the same issue I was seeing and adding a lint-as makes it all good. Thank you!

Great 😄 thank you!

An obvious thing I’m seeing using lsp for diagnostics is that it frequently gets out of sync or stops producing diagnostics. Of course the neovim client is alpha so perhaps there’s more work to be done there...

This can be a "too many open files" problem, I'm also seeing this sometimes in emacs

Also I’m not sure how well Clojure-lsp handles multiple clients at the same time on the same project?

It’s super common to have multiple vim processes running

killall clojure-lsp I did this today ;)

wasn't clojure-lsp killing itself after some time of inactivity @ericdallo?

would make sense maybe

or are these watchers created client side... yeah of course

I would much prefer for now to launch the lsp server manually and see the diagnostics in my console.

But I’m not sure if this is a possibility

you can just use clj-kondo from the console

or disable diagnostics in lsp-mode and use clj-kondo proper (this is what I'm doing)

Not sure, never had a problem like that, but I know Calva already had the same issue

And I already had 4-5 clojure-lsp running for different projects at same time

Also the gets of sync looks a odd issue, we really would need some kind of repro I think

I often get "too many open files"

but I also usually have several projects open at once

What is "too many open files" an lsp-mode error or something?

next time I have it, I'll make a screenshot

but basically all of LSP stops working

Really odd, never saw a error like that

what is your lsp-file-watch-threshold ?

I set it to 10k since else a lot of projects just don't work

this was adviced by the guy on discord

this has to do with lsp-mode not respecting .gitignore

The file watch is just for lsp-mode watch changes on all those files, should not kill anything

I know, but if it doesn't watch any file, you don't get lsp

right?

in any way, I think this is causing the error I'm seeing, because when I killall clojure-lsp it works again

No, imagine something else change a file that is not open on Emacs, with file watch, lsp-mod e will know that and warn lap server. But when you open a file in Emacs, lsp-mod e will manage it anyway

So the file watch is just something more, but not related with lsp in a single file

You can even disable the file watch

I know, but when I get the message, it's blocking something else that should work

And most things should keep working

ok, let me disable it then

how?

Oh, yeah because it's spawning the watches for every files

I think you can just set to nil lsp-file-watch-ignored or something, let me confirm

lsp-enable-file-watchers

ok, I will try this

Not sure what I will be missing, but also not sure why it needs a watcher at all

Git file changes I think it's a example, but I think restarting lsp should fix it though

yeah, I'll rather just do that

Update your clojure-lsp version, it should fix that filter

So just to get it clear, it’s the editor that notifies the LSP server about file changes?

In other words, could the LSP server just watch the files itself

Yes, it's client responsibility to tell server which files to watch

So the server is the one with access to the filesystem? Or does the client sends chunks of text that have changed to the server?

both

Yes, both, but for changes like that, the responsibility is from the client to watch for the file changes

So currently I have a "stuck" lsp server. How can I best debug to see what might be up? /tmp/clojure-lsp... isn't showing up.

Oh wait it's $TMPDIR/clojure-lsp... in macOS

Check for the log file with lsp-clojure-server-info

it should has a key log-file

clojure-lsp.main.LSPTextDocumentService/didChange                         main.clj:  117
                                      clojure-lsp.handlers/did-change                     handlers.clj:   58
                       clojure-lsp.feature.file-management/did-change              file_management.clj:  119
                                                  clojure.core/reduce                         core.clj: 6833
                                          clojure.core.protocols/fn/G                    protocols.clj:   13
                                            clojure.core.protocols/fn                    protocols.clj:   75
                                    clojure.core.protocols/seq-reduce                    protocols.clj:   31
                                          clojure.core.protocols/fn/G                    protocols.clj:   19
                                            clojure.core.protocols/fn                    protocols.clj:  136
                                                                  ...
                    clojure-lsp.feature.file-management/did-change/fn              file_management.clj:  122
                     clojure-lsp.feature.file-management/replace-text              file_management.clj:   96
                          clojure-lsp.feature.file-management/offsets              file_management.clj:   82
                                                                  ...
java.lang.NullPointerException:

(TIL about less -R to handle the ansi escape sequences)

Yeah, it seems a issue on the replace text logic, please open a issue with a minimal repro

So it seems like what's happened is because the didChange handler isn't working, the file gets out of sync, then everything else seems to be working but on the wrong text 😄

Getting a minimal repro might be hard to do but I will give it a try.

The file gets out of sync indeed, but nothing related with file watches, but related with a recent change where we introduced incremental text changes

I can reproduce this consistently with a specific file. I see a lot of debug messages like so:

2021-03-02T19:24:23.733Z frosty.local DEBUG [clojure-lsp.crawler:142] - Cannot find position data when analysing fn* {:name fn*, :filename "/Users/orestis/dev/nosco/nosco-gamma/cljs/nosco/views/idea_single.cljs", :from nosco.views.idea-single, :col nil, :from-var IdeaNavigation, :arity 2, :bucket :var-usages, :row nil, :to cljs.core} nil

that message is not related with the issue, is just a log that I need to avoid logging unecessary

I restart the server, attach a new client, add a new empty line to the file, hit save... boom.

Could you open an issue with the minimal repro please?

It's not exactly minimal, it's a big file I have here. I can probably attach it though?

I will clear the nvim lsp log to get you a clean slate of that too

in a small file/repro the issue doesn't happen?

It does happen on a 50 line file so it's probably not that.

I'm kinda out of it now, I will resume tomorrow morning with a fresh slate.

All I can offer is that it's the didChange handler, and AFAICT from neovim, it's sending always the entire file down the pipes...

hum, it could be a issue with neovim if does not support the incremental text changes

[ DEBUG ] 2021-03-02T20:38:52+0100 ] ...im/HEAD-dc3ca16_1/share/nvim/runtime/lua/vim/lsp/rpc.lua:388 ]	"rpc.send.payload"	{  jsonrpc = "2.0",  method = "textDocument/didChange",  params = {    contentChanges = { {        text = '(ns nosco.react)\n\n\n(defmacro forward-ref!\n  "Takes a component symbol and updates the definition with React.forwardRef,\n  preserving metadata on the component var."\n  [component]\n  `(set! ~component (.forwardRef nosco.react/React ~component)))\n\n\n'      } },    textDocument = {      uri = "file:///Users/orestis/dev/nosco/nosco-gamma/cljs/nosco/react.clj",      version = 3    }  }}

Here's the command that neovim sends on the change. It's the entire text of the buffer.

Hope it gives some light. I'll be off to bed now.. thanks for your time on this project! Please apply for clj-together funding 🙂

I already applied 🤞 😄 It helps, I think clojure-lsp is not considering the full text, I'll take a look on this later today, thanks 👋!

@ericdallo @borkdude thanks to both of you for looking into that issue I created. My bad on the unresolved vars linting! Probably a silly question, but is there any way to like… help automate the creation of :lint-as entries? (Perhaps this is a question better asked in #clj-kondo but)

Np! Yeah, that's something I'd like too

it's a feature I already thought about it, it'd be a clojure-lsp responsibility I think

like, if I see a situation where I need to add a :lint-as, having an easier way to stub it in my clj-kondo/config.edn would be nice. in addition, it would be sweet to be able to select from already understood options

Cursive has that feature indeed

i knew i had seen it somewhere 🙂

Yeah, I think if we could know what is the clj-kondo file used, we could have some kind of code action: Lint as def or Lint as defn

something like that

additionally, some shared repository of common lint-as entries would be nice. i guess it’s kind of like externs or something at that point?

“give me the lint-as stuff for httpkit” for instance

yes, maybe @borkdude already have a repo with some examples?

https://github.com/clj-kondo/config

🎉

one more improvement, clj-kondo could report the finding with some metadata, like suggested lint-as

then clojure-lsp could use that for the code action: Lint as blabla

That's one of the coolest features from Cursive IMO, it'd be really cool to have something like that

one last pie in the sky scenario that would be rad: i often kind of stumble around a project, finding them one at a time. that’s kind of why i mentioned some kind of “stub them all” command.

then i can just focus on filling in the correct lint-as info in the file

or leave them stubbed, but at least there’s a map of what i have provided lint info for vs what i haven’t

does that make sense?

As for: > suggested lint-as You guess is as good as mine. If clj-kondo could make this suggestion it might just already lint it like that.

Which it won't, because it can never guess this right

eh, i suppose that’s harder than it looks… for instance, you wouldn’t want to create lint-as entries for http/get, http/post, etc. since the lint-as {org.httpkit.client/defreq clojure.core/def} is the actual solution

yeah

exactly. people should just PR their configs to the clj-kondo/config project

yes, but that's how cursive suggests I think, it suggests to lint as def or defn or a custom one(?)

or to the corresponding libs and then you will get a message when you lint the deps

that's nice but what if it's the wrong suggestion?

then it’s basically “ignore this” right?

or it has no effect?

yes, I think it's good to have a repo for that, but it's better to make the IDE fix for you. Not sure, only saw folks from work using it

I think clj-kondo.lint-as/def-catch-all might be the best default

since that will try to account for most weird deflike macros

do i understand correctly that maintainers of libs /could/ provide linting definitions as part of their artifacts?

and we could then pick those up?

yes, that's correct

Found it! https://cursive-ide.com/userguide/macros.html

Looks really cool indeed

it seems you can specify a already know var

> Currently this is only supported for a hard-coded list of namespaces for projects which are known to be problematic. If your project uses one of these namespaces, Cursive will prompt you with a notification:

this probably is another future step, I think just suggesting the basic lint as could be really cool/helpful

back to borkdude’s point about just submitting the lint-as defs to maintainers or to the central repo

@devn You can read about that here: https://github.com/clj-kondo/clj-kondo/blob/master/doc/config.md#exporting-and-importing-configuration