Fork me on GitHub

If someone’s interested - for a while we’ve a had a similar issue for CIDER (


Basically the gist of it is that someone needs to extract the old SLIME approach of doing xref from here (, convert it to middleware and we can also use this for replacing occurrences.


I think that this approach that doesn’t rely on actually parsing all namespaces in advance is relatively simple and would yield decent results.


Why does refactor do it differently?


@arrdem @ghsgd2 not aware of cljr being broken. have you tried newest snapshot tho? also a github issue with detailed info would be appreciated if you have a genuine breakage


essentially cljr went down the path of working with ASTs. cljrs find usages is basically an ast based search

New To Clojure10:12:59

@benedek Latest snapshot doesn't seem to work. Successfully evaluated clj-refactor-compat.el buffer. Doing the same for clj-refactor.el which provides clj-refactor and it fails:

Can't find library clj-refactor


nope. if you use packages you need to pull the latest version of cljr via package-list-packages etc


@benedek but not particularly because the other xref system doesn't particularly work very well?


tbh I've never used slime


Hey folks, I'm trying to understand cider-grimoire behavior, specifically in the context of this tweet from Bozhidar which says that grimoire doc lookups in CIDER use the REPL to resolve symbols. As far as I can tell, a cider-grimoire lookup goes to cider-prompt-for-symbol-function, then cider-try-symbol-at-point, then cider-symbol-at-point, which wraps thing-at-point. Which of these relies on a running REPL?


so, from what I understand, the main concern is that in general you want to get the fully qualified name of a symbol in order to do a proper lookup in grimoir


the thing is that thing-at-point may not give it to you, so you need to go to a running repl to get the fully qualified name


now, this is the part that the IDE should handle


if you establish that your library expects only fully qualified names, it can be used by any IDE to run these types of searches


but I'm not entirely sure on what you have in mind


d'oh, I think I see it now—it's in cider-grimoire-lookup


yeah... this bit


(name (nrepl-dict-get var-info "name"))
            (ns (nrepl-dict-get var-info "ns" "clojure.core"))


so what I would do, to achieve modularity, is to forget about that part completely


and try to assume a namespace?


so that your library would expect fully qualified names


hmmm yeah, that's the part i wasn't sure.. you want a stand alone package or more like a library?


because you could just let something else (cider or unrepl or any other repl-connected thing) to figure out the fully qualified name, and leave your library to be in charge of looking that up


without worrying on how to resolve a symbol


i mean, symbol resolution is a different task


well, before I saw this part I was hoping to be a standalone package, so that it would be possible to run without either unrepl or CIDER


but I see the difficulty with that now


you can still provide a prompt, so that the user would insert the resolved symbol there


symbol resolution can be done by the user


that's just as bad as an HTTP delay, really


the other thing is: I don't know grimoir's api, I don't know if you can search with a non qualified symbol and get a list of possible options


would it be possible with their api to get a list of options given a query string?


if so, you could try completing-read


from it looks like I could just assume clojure.core and 90% of use cases would be solved


and that should fail fast, so then look down the list at alternate namespaces. If it exists in, say, both clojure.core and clojure.edn or something, then let them choose


but I don't expect that to be a common issue


so, your idea is to download all grimoire as .md files and search based on their file names, right?


then maybe it shouldn't be that hard that given a name, if you don't find a straight match, you can list all close options


this is a big maybe, I don't know how would be your local .grimoire/ structure


me neither. it's still an open question to arrdem (in a thread a page or so up)


@volrath is right, that’s the main concern.


As I mentioned on twitter you can always try to do some guesswork about the thing at point or just simply adopt an interface where you have to enter something manually and you’d get the possible candidates in ambiguous cases.


With CIDER and unrepl.el we have luxury to avoid this and I think it’s preferable as it leads to better UX.


> from it looks like I could just assume clojure.core and 90% of use cases would be solved


Well, that’s one approach, but it’s going to be pretty annoying for the cases when that’s not right. 🙂


And, of course, you can write your package in a way it relies on a repl-connection when present, and does something else without it. 🙂


Wouldn't it make sense to keep the existence of a REPL outside the concerns of grimoire? "If full namespace provided do X; if given an unqualified var name then do Y" is still possible in that architecture. I think Grimoire doesn't need to know if a REPL exists or not, it just needs to know if the symbol's fully qualified name is known or not.


I agree it will be interesting to see how often "assume ns is clojure.core, if that fails then try the other Grimoire-covered namespaces (in some order?); if the symbol exists in multiple namespaces covered by Grimoire then offer the choice" is annoying.


I'm not familiar with how much disambiguation will be necessary within the domain that Grimoire covers.


> if the symbol exists in multiple namespaces covered by Grimoire then offer the choice” is annoying.


It’s also annoying to be looking for clojure.string/reverse and get the core one 😉


Probably the overlap is not big, but there’s some for sure.


Another option would be to adopt an interface similar to this one -


clojure.core/reverse versus clojure.string/reverse is a good example, thanks. That would be a good reason to want a REPL to differentiate, but in cases where one doesn't it wouldn't be terrible to default to making the user choose (like CIDER often does with Java classes)


Grimoire actually has an undocumented search endpoint which does pretty much what you’re suggesting here - it tries to figure out “which one” you meant based on using its heatmap score to infer the most likely match.

New To Clojure20:12:44

@benedek >not aware of cljr being broken. have you tried newest snapshot tho? It's the same on latest snapshot. >also a github issue with detailed info would be appreciated if you have a genuine breakage Could you please clarify what do you mean by "genuine"? And how to determine whether the breakage is "genuine"? Nevertheless I've reported the breakage: Hope it will be accepted and fixed eventually.


thanks for issue @ghsgd2 i am having a look


by genuine i just meant that without a detailed bug report i have little hope of deciding if there is a problem with your environment/configuration or if there is a real bug/breakage in cljr


sorry if it was a misleading/confusing phrase


i was kinda in a rush.. 🙂


see my answer and workarounds on the issue. also ta for the bug report

New To Clojure22:12:06

@benedek Thank you! I tried to refresh from CIDER repl as suggested:

user> refresh
CompilerException java.lang.RuntimeException: Unable to resolve symbol: refresh in this context, compiling:(*cider-repl example*:1:7527) 
user> (clojure.repl/refresh)
CompilerException java.lang.RuntimeException: No such var: clojure.repl/refresh, compiling:(*cider-repl example*:49:7) 
Going to use (setq cljr-warn-on-eval nil) in the meantime because I need to rename symbols in all project files, not just in one of them.