Yes!

I will add a tries in a loop and log that

I added something similar yesterday

But not for the source-paths discovery

What was the exactly cyclic dependency you added? A local root that points to the same parent or something?

I just managed to repro

Just pushed a fix/improvement

it's a calva issue

ah ok, thanks. i’m guessing theres a ticket already for that?

actually it will fix it as soon a new clojure-lsp version is released

there was, let me find it

ah nice!

https://github.com/BetterThanTomorrow/calva/issues/1373

in the end we reverted because of other issues and found a way to "fix" it on clojure-lsp side

it’s fine, just wanted to let them know, but if you are fixing it anyway i’m happy:)

I'll release clojure-lsp tomorrow probably

ah its all of them again, didn’t try any others yet today apparently

great work, thank you!

https://emacs-lsp.github.io/lsp-mode/page/main-features/#breadcrumb-on-headerline

It's be a use there is a error diagnostic on that segment level

I personally disable that

lsp-headerline-breadcrumb-enable-diagnostics

https://emacs-lsp.github.io/lsp-mode/page/settings/headerline/

I think i understand. Ill probably just disable tthe file path info, i rarely need that context when i'm in the file

Yeah, I implemented the lsp-mode breadcrumb but I need to confess that I don't use it anymore :p

Your lint-as is wrong

lint-as value needs to be a map

yes. I didn't copy it correctly to the comment. It's :lint-as {my-macro/foo defn}

ATM clojure-lsp support only clj-kondo config at project root level

will it support nested clj-kondo configs?

With clojure-lsp ATM no

I think so

interesting. thanks. I wonder why we have this strucute then, maybe something else is using those lint-as rules.

Not sure how hard would be to implement that since we do lint the whole project at start and would need to check if there is kondo config in each linted subdir

Clj-kondo only, supports nested config

Clojure-lsp doesn't

now i just have some-dir as the lsp project and some-dir/.clj-kondo/config with my macro correctly specified, but its still underlined as red. Is there a way to ask lsp what rules it's using to resolve symbols/text to see if my clj-kondo config file is in that list? Output of logs

[Trace - 01:37:28 PM] Sending request 'textDocument/codeAction - (22)'.
Params: {
  "textDocument": {
    "uri": "file:///home/drewverlee/archmedx/kyber/server/src/pathom/resolvers/curriculum/learners.cljs"
  },
  "range": {
    "start": {
      "line": 10,
      "character": 13
    },
    "end": {
      "line": 10,
      "character": 13
    }
  },
  "context": {
    "diagnostics": [
      {
        "tags": [],
        "message": "Unresolved symbol: readiness",
        "source": "clj-kondo",
        "code": "unresolved-symbol",
        "severity": 1,
        "range": {
          "end": {
            "character": 25,
            "line": 10
          },
          "start": {
            "character": 16,
            "line": 10
          }
        }
      }
    ]
  }
}

No, you change kondo config and just make any changes to the file that will be linted with the new config

Also, make sure the project was imported with the current project root on lsp-mode

Via lsp-workspace-folders-remove/add

It scans the deps.edn/project.clj for source-paths discovery only, nothing related with lint/kondo

whats the outcome if your workspace root doesn't have a deps.edn or project.clj?

it can't help with autocomplete on those deps?

source-paths won't be found and some features won't work

why your project doesn't have a deps or project?

is it possible to share you project or create a minimal repro?

Because the project is split across a browser client and a server. They put the .clj-kondo at the root that shared both and the deps in the root/client/deps.edn root/server/deps.edn And then had clj-kondo at multiple levels root/server/.clj-kondo/config root/.clj-kondo/config So for the moment, what i have done is to copied the shared clj-kondo into the 2 projects. Both of which will be separate LSP workspace: root/client/deps.edn + clj-kondo root/server/deps.edn +clj-kondo

yes, that sounds like a valid workaround

Please open an issue about the nested kondo support so we can discuss better how to implement and make lsp support that

That sounds like a good idea. It might be that our project should make a change to. I'm currently too overloaded to think on it further 🙂

@U0DJ4T5U1 what is the reason you have one root clj-kondo and multiple projects?

you can use :config-paths to share configuration in multiple projects

I think that should cover this use case

thanks, ill take a look. :config-paths is an option of clj-kondo right @U04V15CAJ? that wouldn't cover lsp handling a root directory that didn't have a clojure deps file or lein project.clj file. the clj-kondo file was likely intended to be shared between the browser client and the server code. I think CI tooling is using it for both of them.

yes. my suggestion is to have always a .clj-kondo directory in each project and use :config-paths to refer to a shared config from each project

this will also work better for VSCode users on your project

:config-paths ["../../shared-kondo-config"]

so .clj-kondo/../../shared-config

That makes sense, thanks for the pointers!