Fork me on GitHub

@kurt-o-sys tried once and it used to work... haven't tried recently


@bozhidar Congrats for the release! Loads of cool stuff in there


@richiardiandrea well, good to know it can work 🙂. I'm just wondering why it's not 'commiting' the changes, but keeping it in cache. Any ideas how to debug this?


@kurt-o-sys not sure, I would check first of all if the buffer that cider opens is associated with project files or .boot/cache files. Then whether there is a mechanisms to support resolution from one to the other.


the buffers opened are the project files...


Ok then it is weird that clj-refactor even knows about .boot/cache files


a new (cache) buffer, of the file I'm working in, opens when I refactor


It states that x files are changed, it is true: the x cached files do change, but they are not open in the buffer (except the newly opened cache of the one I'm working in)


Uhm seems like there is some sort of resolution going on there I would report it as a bug to maybe clj-refactor first


@kurt-o-sys I think some commands have a known bug with this. To explain why @richiardiandrea, the files are searched for on the classpath.


This is a possible fix (not having looked into it properly):


Right, I saw issue #97, but that does seem to be something else. I checked #422 - it seems to be cljs related. The fix is merged and added to the latest CIDER-nrepl (0.15.0). Using the latest version doesn't solve the problem. It may be related, but it doesn't fix the problem I described (refactor - rename symbol). I don't know if it's related, but here's another issue I have: 1. start a new boot project 2. position yourself on the println in core.clj 3. SPC m r e f (refactor - extract - function) and give it a name 4. see (println... extracted in a new function 5. position yourself on the new function symbol 6. SPC m r i s (refactor - inline - symbol) 7. see a NPE be thrown <- *first issue* (this is different than the case I described before about 'refactor - rename') 8. undo your changes 9. repeat 2 and 3 10. see extracting not working anymore <- *second issue* (restarting the repl and refactoring works again)


Question: is it possible to 'boot/commit' the files from spacemacs/emacs/...? I mean, if I refactor and the only thing I need to do to 'save' the changes is another command, that's no problem at all.


@kurt-o-sys the change in cider wouldn't fix the bug in refactor


nope... well, not in my case. Pretty easy to reproduce: 1. start a new boot project 2. refactor - rename Renaming is done on the cached file.


Sorry, wouldn't fix it.


I'd take a look through how rename symbol locates the location of the symbol.


It'll be in the refactor-nrepl repo


ok, thx... I have no idea, but I might take a look as well 😛


find-symbol operation is used to locate all uses


right... although the file to search in is already set there.


(core/dirs-on-classpath) inside find-global-symbol?


the cp the 'root' of a boot app is inside the cache-dir?


(just guessing)


(->> (core/dirs-on-classpath)
         (mapcat (partial core/find-in-dir (some-fn core/clj-file? core/cljc-file?)))
         (mapcat (partial find-symbol-in-file fully-qualified-name ignore-errors)))
This defines which files are searched, I guess?


The fact is that boot resolution is not bidirectional (AFAIK) so you cannot go back from a file in the cache to a file in the project dir. I don't know because I haven't had time to check if this is the actual problem though and if not I apologise. If it is, probably this is worth a feature request in boot