I made a PR to orchard so that `cider-browse-spec´ can expand ns-aliased keywords https://github.com/clojure-emacs/orchard/pull/42

Got a quick question about hot reloading functionality. I think that it still should be a part of clj-refactor. Why? 1. Clj refactor can use the hot reload functionality when adding the library so the user experience will be much more pleasant. 2. Hotreloading was a part of clj-refactor since the beginning so it should be still there 3. In order to make the user experience smooth I would have to copy and paste the existing functions from clj-refactor. (I mean those which touch adding dependencies) What is your opinion guys?

i thought the discussion was whether it should go into CIDER or clj-refactor. None of those positions argue about where it should live, they just seem to argue that the feature should exist

The question is where the feature should land. Should I put it in clj-refactor?

@dpsutton Do you know how I can add the library with specific hash commit? I wanted to add tools.deps.alpha on jack in but the thing is that for instance leiningen does not allow hash commit as a version of dependency. What I plan to do is simply wrap the call to ’add-lib with emacs-lisp.

no i haven't waded into that stuff

i'm always fine with restarting my repl

@kwcharllie379 I'd argue for it going into CIDER. Hot-loading of dependencies is not really a refactoring task to me. (Along similar lines, I'd argue for separating the functionality of hot-loading a dependency in the running process from the functionality of updating projects.clj or deps.edn to add that dependency--the latter fits more with the spirit of clj-refactor, IMO. I would love to be able to hot-load dependencies without my project files being modified.

I see your point @enn. The case is that if I move the code to cider regarding the hot-load functionality I would then have to move a lot of functions from clj-refactor to cider as well.

I would rather avoid it for now