Thanks! it should be easier than sort-map, issue welcome

On Emacs I use both dev and test alias and never had any issues

maybe @U0ETXRFEW or @U02EMBDU2JU know?

thanks. if I remove :main-opts, it works, because Calva is able to add its own "-m nrepl.cmdline"

I wonder why calva does that, I think it's different how cider does?

Calva detects the problem and gives a warning about it, so it seems to be that way by design.

We have a ticket somewhere to do the same thing as cider, but for now I just have a :test alias that includes the sources and a :test-run alias that actually runs them

CIDER used to have this problem. https://github.com/clojure-emacs/cider/issues/2941 . The problem is that if a profile specifies main opts, those “win” and any inline main opts at the end become further args i think? Now CIDER makes its own main args into an -Sdeps form and then ensures that that alias is last so those main opts “win”

I think if -A would start ignoring main-opts (i believe this is a future behavior that is coming eventually) this problem goes away

Another +1 for splitting your current :test alias in two: in all my projects I either have :test and :runner (with :main-opts only in the latter) so it's easier to start a REPL with test dependencies) or I use :exec-fn/`:exec-args` instead of :main-opts in :test so I can use -A:test for a REPL etc and -X:test to actually run tests.

(in several projects, I've added build.clj and have my test running machinery in that, so that it's easier to do automated multi-version testing -- so :test will have no :main-opts and clojure -M:build test is how I run tests)

As the release notes said, you can turn the feature on by adding :experimental {:dep-graph-queries true} to your .lsp/config.edn file. It’s a pretty pervasive change to how clojure-lsp works so it’s hard to pinpoint exactly what to look for. If all goes well, your experience shouldn’t change much, except that clojure-lsp should respond faster as you’re using it, especially when getting completions or finding definitions, references, and implementations. The effect will be more noticeable for those of you who typically work in large projects. But, if you see results that seem incomplete or see errors in the logs, please report them here. I can help track down what’s going on. And even if you don’t notice any problems, it’d help if you reported back in a few days that things are going OK. We hope to take this feature out of beta soon, turning it on for everyone all the time, so we’d like a little proof that it’s stable.

oh i put that change in .lsp/config.edn but it needs to go in .lsp/settings.edn?

(and I work at Metabase so i’ll be using it on that large codebase)

also, is there a way to verify that I’m using the new feature versus just “it feels faster” but i never hit the new codepath at all?

Ah thanks @U11BV7MTK… my bad. I meant .lsp/config.edn

The short answer is, no, there’s no easy way to verify the feature is on. You could check the performance of completion. I did a decent amount of testing of this feature on metabase, so I know that it speeds up completion quite a bit in that project. You may even try disabling the completion throttling in your editor. clojure-lsp scans its config.edn file for changes every few seconds, so another way to check is to run an action, toggle the flag in the config file, wait a few seconds, and then run the action again. If you notice a speed difference, then it’s working. But it’s a good point—it might be easier to confirm if we add a log line when the feature is detected. I’ll think about how to do that

I think there is a better way to confirm: on emacs lsp-clojure-server-info should bring lots of info including the settings clojure-lsp is using final-settings if the dep-graphs setting is there, it's being used

nice i see :experimental {:dep-graph-queries true}, in there. thanks @ericdallo

I'm giving it a go too

Tagging some people I know may be interested on that @UMMMKKADU @UEENNMX0T @U02EMBDU2JU @U04V15CAJ

I’ve already turned it on! Haven’t specifically noticed a difference yet but so far it works as expected. I’ll keep an eye out for speed increases when I load up my bigger projects today

yeah, seems to be transparently working for me atm. I'm not used to my new config enough to know if it is faster or slower

do you know about this or should I create an issue?

@UL05W6AEM could you check server logs for java logs?

I add vim.lsp.set_log_level("debug") in vim init, opened clojure file with one of the lines containing (Integer/parseInt "1") and tried to go-to-definition

This seems to be the log from nvim, could you get the server logs? https://clojure-lsp.io/troubleshooting/#server-log

set up {:log-path "/tmp/clojure-lsp.out"} Did the same, as above, here is the file.

Right, so can you delete ~/.cache/clojure-lsp and .lsp/.cache , restart server and get that log?

It works after removing the cache

Thanks!

Probably some conflict with a older version which saved a outdated cache, LMK if it happens again