As a brief comment on the topic above, currently I use a mixture of refactor-nrepl (used as a vanilla API) and https://github.com/gfredericks/how-to-ns . Needs some hacking tbh. But at the same time you can get it to very precise since since it partly relies on runtime insights (or you can make it so in your own wrapper)

I'd be happy for a lsp-based solution that worked OOTB without so much hacking. When used as an API (as opposed from having perf constraints coming from the IDE usage context) it could be a little smarter than by default by e.g. inspecting ns-interns?

@vemv afaik clojure-lsp is only based on static analysis (mostly provided by clj-kondo) and works as a static binary (so it can't inspect your runtime really)

Yes, the thing is that there's an API in the roadmap/hammock? The nice thing about such an API is that you could optionally augment the info it has access to

yes, this augmentation is usually the config file

I started working on the API this weekend 🙂 so it'll be possible to use for example clean-ns refactoring via cli or REPL

it could of course do additional things in JVM mode and inspect your REPL state, but that would make it a bit different than how lsp works currently. the idea eric and I had was to expose the logic it had now via a CLI or API (and/or bb pod, for scripting, etc)

> yes, this augmentation is usually the config file yeah I get this but ideally I'd have a program compute the config for me :) as you might imagine a good chunk of lisp devs have this ideal

personally I really appreciate both approaches (static vs runtimey), more often than not one can get a flexible impl

this has been going on in my mind as well: emit some file from the runtime state and augment static analysis. e.g. that's being done here as well: https://github.com/clj-kondo/inspector

but the generation of such files can be done outside of the tool, as long as the tool understands the input

also you'll run into the problem that your emitted runtime state might have changed and your file isn't up to date anymore, i.e the "dirty REPL state" problem

e.g. I considered an nREPL client in clj-kondo which could peek into your nREPL session to get extra var information

but the nice thing about clj-kondo now is that it will actually tell you that a function doesn't exist, if it doesn't exist in the source, but it may still be there in the REPL

but I guess if you emit this info from a "clean" REPL, it could work

but then the info goes out of date pretty quickly once you start editing

Sometimes I wonder if a REPL feature that auto re-eval your changed var if it compiles correctly would be useful

> this has been going on in my mind as well: emit some file from the runtime state and augment static analysis. e.g. that's being done here as well that's very nice :) re dirty repls, that's one problem that doesn't happen under a reloaded workflow. It can be really great to integrate formatting/linting with refreshing. Then again it's not everyone's jam

yes, I tried the reloaded workflow but it wasn't for me

but in a CI / CLI scenario I guess it doesn't matter

you'll "fix" problems based on the current state of the runtime immediately after loading

> Sometimes I wonder if a REPL feature that auto re-eval your changed var if it compiles correctly would be useful yes I sometimes kinda want to refresh only if clj-kondo doesn't emit warns for the current sources. Could shave some seconds

I guess you could build that into your reloaded workflow by using clj-kondo as a JVM lib

Yes.... maybe one day! Honestly my #1 linter (I say this as someone that maintains another linter lib) is "don't make mistakes". Surprisingly effective ;p So generally I care more about them in CI

I do have a git pre-commit hook to lint changed source in my work project, so I don't commit lint warnings

I use clj-kondo way more in my editor than CI, but it's nice that everyone can use these tools how they want it

And soon clojure-lsp on CI 😛

yep :-D