clj-light-refactor
clj-light-refactor copied to clipboard
Rename-symbol breaks when renaming a private symbol being accessed via #'
I am trying to use your refactoring tools on a test project in https://github.com/JustinSpedding/luminus-testing
When I try to rename the validate-new-message symbol to validate-new-message2 in lum.repositories.messages, it works fine within that file. However, it screws up the unit test symbols in lum.test.repositories.messages. It changes #'message-repo/validate-new-message to #'message-rvalidate-new-message2sage
When I rename a public symbol, it work fine.
I just tried adding some extra indentation before the lines that the rename-symbol messed up. When it searches for the usage of the symbol, it does not account for the indentation in the beginning of the line. If the first non-whitespace character is the first character of the line, it works fine. If there are 6 characters of whitespace in the beginning, it will replace the text 6 characters to the left of where it should.
Ouch. Been a long time since this plugin got any love. There is bound to be some bitrot (: It could be that the refactor-nrepl used has a bug and I haven't really tried any newer versions in a long time.
Regrettably I don't have time for another couple of weeks to look at this. If you are up for it you can try to do some debugging in this file: https://github.com/rundis/clj-light-refactor/blob/master/src/lt/plugins/cljrefactor/usages.cljs ... but I completely will understand if that doesn't seem to tempting :-)
tx for the report !
I did a little digging. In a different project of mine, it always replaces the text immediately before the parens at the end of the line containing the private symbol being referenced by #'. Strange.
I looked at the code in the usages namespace, and nothing immediately stood out as wrong to me. However, I was confused by the origin? function in create-replace-selections. What is its purpose, and why do you calculate the text selection that way if it is false?
Anyways, I will try different versions of refactor-nrepl and cider-nrepl to see if a bug was introduced in some version of those libraries.
Hello, again. I forgot about this bug for a while and just remembered that it was never resolved. Have you looked into it at all?