This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # adventofcode (62)
- # beginners (78)
- # boot (26)
- # boot-dev (9)
- # cider (73)
- # cljs-dev (33)
- # cljsrn (36)
- # clojure (159)
- # clojure-android (1)
- # clojure-austin (1)
- # clojure-greece (79)
- # clojure-italy (10)
- # clojure-nl (3)
- # clojure-russia (11)
- # clojure-spec (33)
- # clojure-uk (26)
- # clojurescript (107)
- # core-async (22)
- # core-logic (12)
- # cursive (16)
- # datomic (13)
- # devcards (5)
- # duct (36)
- # emacs (4)
- # figwheel (3)
- # fulcro (107)
- # graphql (171)
- # hoplon (27)
- # instaparse (24)
- # jobs-discuss (34)
- # juxt (3)
- # lein-figwheel (1)
- # leiningen (8)
- # lumo (11)
- # off-topic (9)
- # onyx (79)
- # parinfer (1)
- # pedestal (75)
- # re-frame (27)
- # rum (1)
- # shadow-cljs (11)
- # spacemacs (20)
- # specter (17)
- # unrepl (96)
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.
essentially cljr went down the path of working with ASTs. cljrs find usages is basically an ast based search
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?
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-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
if you establish that your library expects only fully qualified names, it can be used by any IDE to run these types of searches
(name (nrepl-dict-get var-info "name")) (ns (nrepl-dict-get var-info "ns" "clojure.core"))
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
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
you can still provide a prompt, so that the user would insert the resolved symbol there
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
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
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
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.
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)
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.
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
@benedek Thank you! I tried to refresh from CIDER repl as suggested:
Going to use
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)
(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.