@U2ERGD6UD Does this help? https://github.com/clj-kondo/clj-kondo/blob/master/analysis/README.md

That is all the data that lsp itself uses, but lsp also does some processing on that and can export its own format using clojure-lsp dump (WARNING: it's a lot of data)

I know, I can run clj-kondo and get the data I need. But my project is big and it takes a while. And since Emacs already has started clojure-lsp , I hoped I can reuse this instance so I don`t have to run it twice.

... clojure-lsp already has the data in memory - Is there a way to access it?

I don't really understand the internals of LSP protocol, but could it be used to get the analysis data in raw (EDN)?

I'll defer to @UKFSJSM38 but these details, but I don't think so at the moment

It's possible and easy to access that data via editor but clojure-lsp doesn't support dump via editor yet, but would be easy to add, would you mind creating a issue for that @U2ERGD6UD? We could offer a function to return that info via a custom request, but I'd like to understand how you want to use the info, if via a Elisp function(if using Emacs) or something else

wouldn't opening that data in your editor crash your editor? ;)

Yeah, exactly, that's why I'd like to understand what you would do with that data, probably saving to a file would be a best option

Well, going through the editor seams not right. I want the data in Clojure. To generate charts/graphs in a Clerk notebook. So I have a running REPL where I would like to access the data.

So maybe using clojure-lsp.api that already exists?

You can't really link to the running clojure-lsp as if it's a graal image, a repl won't work

But for a running jvm clojure-lsp it's already possible via lsp-clojure-connect-nrepl-server that I use for debugging purposes

I think for your case may be a good idea use clojure-lsp JVM in your editor so you could do that

Ok, say I use jvm lsp. How do I access the kondo analysis data?

Do you use Emacs?

yes

I mean, is there an atom holding it?

lsp-clojure-nrepl-connect (or something, can recall the exact name right now), will connect cider to the nrepl running in clojure-lsp of your editor

Then you can use the clojure-lsp.api to access functions that provide kondo analysis

Thank you! Again!

@U2ERGD6UD check clj-kondo channel for LSP docs on how to running the most recent LSP + kondo + nREPL (typed this on phone)

It works too, but it doesn't need to be the most recent master to do that, https://clojure-lsp.io/installation/#embedded-jar-legacy-executable from lastest release is already enough

I could include lsp-clojure as a dependency to my existing REPL with Clerk. And then start the lsp/kondo analysis via API. Correct?

No, then my editor will not connect.

exactly

the process running your editor is separated from your REPL with Clerk

Yo have to include a (http) server in clojure-lsp 😉

I think it's best to avoid that:joy:

@U2ERGD6UD Here is how you can start lsp along with any other deps in an nREPL server:

It looks like the functions in clojure-lsp.api print the analysis data. Can I get to the data directly?

Yes, just pass the :raw option

What function are you calling?

Not sure which one. Now trying `dump

You mean {:analysis {:type :raw}}?

{:output :raw} probably...

yes, output

actually, not really, that option doesn't exist

check the docstring or cljdocs

ok, so the analysis data is in the resulting value. can I dispable printing the output?

let me confirm

the docs are missing mention, but you can just pass :raw? true and should not have any print, only the result

I will improve the docs

{:output :none} or {:output nil} would be nice...

yeah, not sure would be possible to support :output nil as some commands didn't have the output, would cause a breaking change

and :output is already a map on some commands, so would be weird I think to support :output :none

ok. :raw? true works. thank you!

I thought about :output :raw? but I don't like that much the raw as well

I would prefer :raw true and :output :raw ;)

you mean :output :raw true for the latter?

If shape of :output can not be changed, perhaps a new option :no-output true would be more clear.

output is already a map for some functions but not for others (which I intend to fix now), but if we introduce a :output :raw as a keyword value, we would cause breaking changes for commands that didn't call :output (because didn't exist)

@U2ERGD6UD would look weird for commands that already have :output right?

But why have the :raw there? The option does not change the output. It disables it. And the function result does not change. I find "raw" misleading. Should be "none" oder "disabled" or something...

yep, a legacy from clojure-lsp.main which uses internal-api as well, clojure-lsp --raw , I agree we could have :output :something true

also maybe output is not a good place to specify whether should print to stdout or not :) output means the output of the function, if will use edn, json, canonical-paths etc, but not the stdout print

naming is hard indeed 😂

maybe :silent or something which is really what raw was intended for since the beginning

Another idea: {:output {:target :std-out}} as default with possibility of {:output {:target :none}}

but isn't the function return a target of a output as well 😂 ? :output :quiet ? I'm out of ideas already..

Perhaps dump should not print at all and just return a value. And then have a new start with dump!

yeah, I think that was accidentally, we could fix it only for dump

The removal of the let is quite recent but beautiful indeed :)

Probably it's not the same case but cider-eval-last-sexp-and-replace does the same magic.

@U1EP3BZ3Q I think borkdude is sharing about the inline symbol feature which allows you to remove a local or var and replace with its real code

an eval would get only the result and not really the entire code being used considering other vars and locals

yes, so

(let [x 1 y 2] (+ x y)) would become `(+ 1 2)

definitely useful

Also, No repl connected required :)

actually, no repl no life :)

yeah, repl is awesome, but if I can get some or most features without the need to connect and eval a huge project, I'm even happier

I always say that clj-kondo is there not to replace the REPL but to optimize the time you spend in the REPL, since you can spot issues early, you don't even have to bother to eval it

yes, I think this is a performance issue in cljfmt + a lot of calls that probably should not happen in clojure-align. One thing that happens is that lsp-mode changes indent-region via a variable to use lsp for format regions in clojure buffers, you can disable that and rely on lsp-format-buffer or region manually which is what most people do

(setq lsp-enable-indentation nil)

https://github.com/emacs-lsp/lsp-mode/blob/781889628b9e0504fde279371548149deae4849d/lsp-mode.el#L4094 that does that

cool, that is what I noticed. There may be some low hanging fruit in the clojure-align function that may reduce the number of necessary calls to indent-region

yeah, there are probably quick wins in cljfmt as well

thanks for confirming!

just FYI, looks like there may be a solution that would move this to a single cljfmt call: [align associative (Attempt to solve issue #36) by reutsharabani · Pull Request #299 · weavejester/cljfmt](https://github.com/weavejester/cljfmt/pull/299)

ah yea, I'm following that issue 😛 really looking forward to have align associative in cljfmt, it's the only big feature I miss from cljfmt

last thing would be column limit, which I think would probably end the split-braining between cljfmt and zprint

oh, that'd be nice indeed

I do have in my backlog add support for zprint as formatting provider because of those things cljfmt doesn't have

but if cljfmt manages to fix at least the vertical align, would be really good