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

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

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

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

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

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)