If someone’s interested - for a while we’ve a had a similar issue for CIDER (https://github.com/clojure-emacs/cider/issues/1840)

Basically the gist of it is that someone needs to extract the old SLIME approach of doing xref from here (https://github.com/technomancy/swank-clojure/blob/master/src/swank/commands/xref.clj), 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

cc @dominicm

Is it enough to load into Emacs https://github.com/clojure-emacs/clj-refactor.el/blob/master/clj-refactor.el https://github.com/clojure-emacs/clj-refactor.el/blob/master/clj-refactor-compat.el to have latest snapshot?

@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 https://twitter.com/bbatsov/status/941281929390907392 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

right

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"))

genau

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 https://www.conj.io/heatmap 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?

roughly yes

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)

but I agree

👍

thanks

@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 https://www.conj.io/heatmap 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 - https://github.com/clojure-emacs/clojure-cheatsheet

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)

True.

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.

@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: https://github.com/clojure-emacs/clj-refactor.el/issues/401 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.. 🙂

@benedek no worries 🙂

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

@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)