Fork me on GitHub
#cider
<
2017-12-14
>
bozhidar07:12:13

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

bozhidar07:12:08

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.

bozhidar07:12:57

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

dominicm08:12:56

Why does refactor do it differently?

benedek10:12:00

@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

benedek10:12:55

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

benedek10:12:05

cc @dominicm

ghsgd210: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

benedek11:12:40

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

dominicm12:12:40

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

benedek12:12:37

tbh I've never used slime

daveliepmann13:12:53

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?

volrath13:12:39

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

volrath13:12:05

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

volrath13:12:16

now, this is the part that the IDE should handle

volrath13:12:08

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

volrath13:12:30

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

daveliepmann14:12:15

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

volrath14:12:26

yeah... this bit

volrath14:12:39

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

volrath14:12:16

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

daveliepmann14:12:28

and try to assume a namespace?

volrath14:12:28

so that your library would expect fully qualified names

volrath14:12:10

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

volrath14:12:04

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

volrath14:12:22

without worrying on how to resolve a symbol

volrath14:12:50

i mean, symbol resolution is a different task

daveliepmann14:12:01

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

daveliepmann14:12:20

but I see the difficulty with that now

volrath14:12:34

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

volrath14:12:53

symbol resolution can be done by the user

daveliepmann14:12:17

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

volrath14:12:51

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

volrath14:12:57

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

volrath14:12:08

if so, you could try completing-read

daveliepmann14:12:34

from https://www.conj.io/heatmap it looks like I could just assume clojure.core and 90% of use cases would be solved

daveliepmann14:12:44

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

daveliepmann14:12:07

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

volrath14:12:08

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

volrath14:12:25

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

volrath14:12:02

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

daveliepmann14:12:49

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

bozhidar14:12:00

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

bozhidar14:12:52

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.

bozhidar14:12:25

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

bozhidar14:12:06

> from https://www.conj.io/heatmap it looks like I could just assume clojure.core and 90% of use cases would be solved

bozhidar14:12:26

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

bozhidar14:12:02

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. 🙂

daveliepmann14:12:15

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.

daveliepmann14:12:51

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.

daveliepmann14:12:48

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

bozhidar15:12:41

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

bozhidar15:12:59

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

bozhidar15:12:42

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

bozhidar15:12:37

Another option would be to adopt an interface similar to this one - https://github.com/clojure-emacs/clojure-cheatsheet

daveliepmann15:12:30

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)

arrdem19:12:33

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.

ghsgd220: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: https://github.com/clojure-emacs/clj-refactor.el/issues/401 Hope it will be accepted and fixed eventually.

benedek20:12:54

thanks for issue @ghsgd2 i am having a look

benedek20:12:34

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

benedek20:12:46

sorry if it was a misleading/confusing phrase

benedek20:12:08

i was kinda in a rush.. 🙂

ghsgd220:12:42

@benedek no worries 🙂

benedek21:12:54

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

ghsgd222: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.