yeah, it could work indeed

we have that for editor already, so we could make available for the API as well

actually, I think we already support for namespaces

like

(clojure-lsp.api/rename! {:from 'my-project.some
                          :to 'my-project.bar})

about folders rename, this is not possible yet, it's something kind of big we need to change on server side yet

> actually, I think we already support for namespaces ah yeah I think I heard of that :) I read the API doc too quickly. Probably Rename a symbol and its definitions across the project. could be expanded accordingly

yes, we have this: > :from the full qualified symbol origin name that should be renamed. e.g. my-project/my-var or my-project.foo for namespaces > :to the full qualified symbol that will replace the original symbol. e.g. my-project/my-var-2 or my-project.bar for namespaces But we could improve the first phrase indeed

> about folders rename, this is not possible yet, it's something kind of big we need to change on server side yet may I know what it would involve? if it's a pure clj+rewrite-clj thing I might be able to contribute a first impl

my idea is to implement the new https://microsoft.github.io/language-server-protocol/specifications/specification-current/#workspace_didRenameFiles fixing https://github.com/clojure-lsp/clojure-lsp/issues/552

that would probably be different for the API, not sure yet

perhaps a cheap-enough thing I can do atm (saving the need for coordination / diving into impls) is considering that "rename dir" is simply a clojure-lsp.api/rename! within a doseq :) with a little wrapping logic for discovering existing namespaces out of a ns prefix (which is easy from a repl environment, which is my use case)

sounds good to me :)

the rename folder thing for editors would probably behave different, so I think they are really 2 different things indeed

I see! nses != files

lastly, I'll need a refresher on a couple things: what's your perception on the reliability of rename!? I'd assume is renames metadata, metametadata, various ns-qualified syntaxes, quoted symbols, var references, refs within comments... is there any such thing that might not get renamed? how's the cljs support for this op? I think last time I asked, the answer was 'it should work' but without so much of a guarantee. Has the cljs front improved lately? (I would assume so!)

> what's your perception on the reliability of `rename!`? I'd assume is renames metadata, metametadata, various ns-qualified syntaxes, quoted symbols, var references, refs within comments... is there any such thing that might not get renamed? ATM if it's a namespace, it renames all the references for that namespace (including on keywords, on master), otherwise it renames a var and all it references, not sure if there are corner cases, if there are I'm not aware of it yet, please let me know > how's the cljs support for this op? I think last time I asked, the answer was 'it should work' but without so much of a guarantee. Has the cljs front improved lately? (I would assume so!) (edited) We had some improvements on cljc files, so it should work as well, but again, let me know if any issues or corner cases, I'm not a heavy cljs user

the API rename! is very close to the same we have on editor LSP, so it uses static analysis, nothing checking the the var usage from runtime

actually, the whole API relies on the same static analysis from LSP on editor

yeah I'd assume it's all static. I have no issue with that, although perhaps in a future I'd look into a way for 'augmenting' it w/ runtime insights (probably I mentioned that at some point already)

thanks for all the info! I have a good use case at hand so probably I'll have sth interesting to report back :) 🍻

yes, I agree

cool, thanks :) 🍻

Not really, without lsp4j you don't have the necessary classes for a lot of core things And datalevin for cache analysis which we still use in repl

Not sure there is anything we could remove or move to another profile :/

hmmm. using rename! as specific example, I'd expect that its impl can be categorized into either its 'functional core' (clj-kondo analysis in, rewrite-clj ops out) and its 'imperative shell' (interact with lsp to perform side-effects, use datalevin as a cache, etc) can the impl viewed as having roughly that shape? (maybe squinting enough)

so ideally I would only consume that functional core it could be as simple as require ing only such namespaces, and excluding datalevin via :exclusions at Maven level might be an arduous refactoring though, idk

Yeah, ideally that makes sense, but I think the current arch is not ready for that

Probably refactoring to use components would help on that

Got it. If you have a GH issue I'd gladly subscribe, will be curious about how it evolves

We don't have it, please open one about it if you don't mind