Fork me on GitHub
#lsp
<
2021-11-08
>
vemv21:11:58

👋 taking a look at https://cljdoc.org/d/com.github.clojure-lsp/clojure-lsp/2021.11.02-15.24.47/api/clojure-lsp.api#rename! could a similar op be offered for renaming a whole file? dir also? (I have no idea whether that is supported at editor level - I'm only interested in the API part atm)

ericdallo22:11:33

yeah, it could work indeed

ericdallo22:11:44

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

ericdallo22:11:52

actually, I think we already support for namespaces

ericdallo22:11:36

like

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

ericdallo22:11:10

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

vemv22:11:08

> 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

ericdallo22:11:13

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

👍 1
vemv22:11:37

> 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

ericdallo22:11:47

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

vemv22:11:15

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)

ericdallo22:11:17

sounds good to me :)

ericdallo22:11:05

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

👍 1
vemv22:11:56

I see! nses != files

vemv22:11:12

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!)

ericdallo22:11:09

> 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

ericdallo22:11:46

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

ericdallo22:11:18

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

vemv22:11:35

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)

vemv22:11:10

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

ericdallo22:11:19

yes, I agree

ericdallo22:11:38

cool, thanks :) 🍻

vemv22:11:45

Another topic, checking out https://github.com/clojure-lsp/clojure-lsp/blob/master/deps.edn, the :deps tree looks somewhat scary. One thing I've been meaning for a while is introducing lsp for refactor-nrepl, but in projects of the cider family, we try to keep dep trees small. They all go through mranderson . It's best to not feed it a lot of stuff IMO. So my question is, if I were to consume the API from a cider-like environment, what could be skipped? Surely the core deps would be rewrite-clj + clj-kondo. While lsp4j or datalevin might make less sense for my use case.

ericdallo23:11:37

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

ericdallo23:11:54

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

vemv23:11:52

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)

vemv23:11:54

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

ericdallo23:11:38

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

ericdallo23:11:53

Probably refactoring to use components would help on that

vemv23:11:12

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

ericdallo23:11:54

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

👍 1