@U04V15CAJ in the following code, we can't find definition of bar in toString

(deftype Foo [bar]
  Object
  (toString [_this]
    bar))

it seems the bar on the arity is missing locals analysis

issue welcome

we don't have semantic tokens for that bar because of the same issue

I can probably address this on Wednesday or so

https://github.com/clj-kondo/clj-kondo/issues/1612

I just made a commit improving the project organization in some aspects, I ended up renaming common -> protocols since it's what it is now, I moved all functions that were on common to lib since they were used only there. Now we have basically 2 protocols in a namespace on protocols. I'd like to externalize lsp4clj to be able to be used on other projects, the issue is that it depends on protocols still. I was thinking on moving those protocols to lsp4clj and kill that protocols subproject but the issue is that lib depends on that and doing that would result on lib depending on lsp4clj which is not good because would bring all lsp4j deps to lib . So, to do that, I can't see other way without having a separated lsp4clj-protocols to be used by both clojure-lsp and lsp4clj, which is not bad too, we could even have that as a sub-project of lsp4clj repo

Any thoughts @U02EMBDU2JU @U07M2C8TT

This would be the summary of projects/subprojects: repo lsp4clj • subproject protocols • subproject core (`lib` or something like that?) repo clojure-lsp • subproject lib • subproject cli Jars: com.github.clojure-lsp/lsp4clj com.github.clojure-lsp/lsp4clj-protocols com.github.clojure-lsp/clojure-lsp

Which protocols does clojure-lsp.lib need?

Both ILSPFeatureHandler and IProducer

You actually want 4 jars: com.github.clojure-lsp/lsp4clj com.github.clojure-lsp/lsp4clj-protocols com.github.clojure-lsp/clojure-lsp-standalone com.github.clojure-lsp/clojure-lsp-lib right? It would actually be possible to get rid of the protocols jar if we push the protocols into lsp4clj and the implementation into clojure-lsp/cli. The actual implementation can still be in lib, just putting together the protocol with the functions would be in clojure-lsp/cli.

The reason I liked common is that it gave us a space to put db, filesystem, and other namespaces that can provide utilities for implementing other LSPs. If all those infrastructure ns’s get moved into “common” it makes sense to have the protocols in there as well. If you don’t want to move those infrastructure things out, then we could potentially get rid of that jar

dependency wise my vision was: common -> nothing lsp4clj -> lsp4clj/common clojure-lsp/lib -> lsp4clj/common clojure-lsp/cli -> lsp4clj/common, lsp4clj, lsp4clj/common

Ah no sorry, I was wrong. You can’t get rid of lsp4clj/protocols since lib needs to call on the IProducer functions, sorry! I was just thinking about ILSPFeature…

Yep

yeah so you’re completely right about the setup, just with 4 jars instead of 3

My first idea was to move to lsp4clj until noticed the same

at least I was not the only one to make that mistake 🙂

To be honest, I'd love to kill common, and do not have more things there, having it as protocols is already a good thing, I already had too many issues with common libs

Mhh, so do you not want to move db and similar out of clojure-lsp? I’d like some of that available as a lsp4clj user 😛

Yeah, not really, db is really specific to clojure-lsp, we may want to externalize the concept, but not the implementation like transit

Or don't export at all

IMO lsp4clj should be lsp4j but with things for clojure

In the future we may even drop lsp4j and have everything in clojure which may help remove a lot of lsp4j deps

Yeah makes sense. I was also thinking more of the concept than transit. The same goes for some of the things in config and settings.

I think it will help me to keep these concepts in mind when I move our lsp on top of lsp4clj and see which common functionality I need and might extract in a more general way. Just not sure where to put that functionality then 😉

Most lap clients doesn't have that settings concept, but I can see how convenient this would be, we could have that on lsp4clj core indeed, but needs more hammock probably

It’s good that our lsp is also split into a lib and cli part, so I won’t be tempted to cross that boundary hopefully

BTW thank you for being so open and receptive to my ideas ❤️ I know this change actually makes clojure-lsp harder to build/develop so it’s much appreciated that you’re so helpful

Np, I was actually expecting to do something like that to help maintaining and evolving the project, thanks for the help