Probably, I'm not sure as well 😅

we need to confirm that

A follow up question is should it change the keyword if it is inside a .edn file? I used the rename namespace today and found it helpful but it got me thinking if it should try harder to find all possible changes.

yeah, ATM it does not and IMO it's safer do not change edn files

BTW, answering your question, we don't rename the keyword if using as full like:

:foo.bar/x

(:require [foo.bar :as b])

::b/x

(:require [bar.baz :as b])

::b/x

In this case was an integrant configuration filé so the rename was necessary. I would guess that most of the time this is true, but I agree that it could cause problems.

I'm not sure why we decided to not rename full qualified keywords when renaming ns though :thinking_face:

Yeah, using an alias makes it impossible to miss the rename. But those doesn't exist on edn files 😉

yes

I think they are 2 different issues/features: renaming consider edn renaming ns consider renaming keywords that use that ns

I agree, 2 separate issues.

And thanks for clojure-lsp, it helps a lot on renaming, enough for me to do many more of them 👏

Thanks :) The edn one could work, but ATM clj-kondo doesn't provide analysis on edn files AFAIK, still an issue is welcome. The other one probably needs to be implemented, I'm not remembering why we decided at the time to not allow that, a issue may help discuss that

there is one use case where changing keys might cause some unexpected effects: 1. change namespace from foo.bar -> baz.bar 2. add namespace foo.bar 3. move some code from baz.bar to foo.bar In that case automaticaly changed keywords can cause some extra steps of refactoring.

Issues: https://github.com/clojure-lsp/clojure-lsp/issues/573 https://github.com/clojure-lsp/clojure-lsp/issues/574

@U04V4KLKC could you elaborate your example on the issue please?

I’m often begin writing code in single namespace (let’s call it foo.bar) and when it starts to be big enough I extract some functions using following steps: • rename entire namespace foo.bar -> foo.bar.lib • create empty foo.bar • move some functions from foo.bar.lib back to foo.bar After that foo.bar can require foo.bar.lib to have access to the rest of functionality. Normally foo.bar exposes api for the program, sometimes via implementation for integrant keys. If during the step 1 such keys will be changed without notice in some file it might break my program.

yes, that could happen indeed, yet not sure how ofter this flow happens for other users, it's something to consider

maybe a opt-out flag would work

yes, option would be great