Clojurians Log v2
nrepl
With Calva looking up info on first in (. clojure.lang.RT (first coll)) below takes you to the def . Is there something I can do to at least say “can’t look this up” or something?
(def
^{:arglists '([coll])
:doc "Returns the first item in the collection. Calls seq on its
argument. If coll is nil, returns nil."
:added "1.0"
:static true}
first (fn ^:static first [coll] (. clojure.lang.RT (first coll))))Calva uses info for this.
What cider-nrepl version are you on right now?
Ah, wait. Do you consider this behavior "wrong"?
nrepl: 1.3.1
cider-nrepl: 0.52.1info doesn't use any context, and first is a valid function, so this is not really a bug in nrepl or cider-nrepl
I’m not saying it is a bug. 😃 I am wondering if there is something I could do differently to not give this wrong answer to the Calva user.
CIDER treats it as first function too, e.g. the minibuffer hint:
Calva is proud of being distilled from CIDER.
I think part of this is that I suck a bit at reading interop code like that. So at first it looked like a recursive call, which didn’t make sense, then command-clicking seemed to confirm. 😃
I guess my hope was that there was a way to provide context.
Unless you employ a full-blown parser/analyzer to process the whole top-level form first and understand what kind of first you are looking at, there is not really a way to do it, and it doesn't make the answer strictly wrong
Which is probably possible to do and may be beneficial, albeit mostly for other cases where context matters.
Cue this form:
(let [first second]
(first coll))first here will also be "wrong"Actually, there is a way to pass precisely "context" to info, but it doesn't handle such interop cases
If you feel this is important, you can consider submitting a fix for it. I'm still wondering how useful that will be. I've never seen this raw interop form anywhere beyond clojure.core.
Ah, looks like I should provide context at least, even if it doesn’t handle these cases.
Doesn’t look like it handles the let binding case, either, right?
Nope
It only improves lookups for cases like (.someMethod ^MyClass x)
Where the presence of the type hint helps cider-nrepl pick up the target class for info
Calva allows the user to choose between prioritizing dynamic (nrepl) lookup info and static (clojure-lsp). Default is dynamic, because that makes the most sense to me. But here clojure-lsp makes the correcter call for both cases. It does use a full blown parser, so not so strange.
And I assume if it were (. clojure.lang.RT (contains something)) then it would work because contains is not a valid function
I wasn’t here to suggest changes to how cider-nrepl does it. But to get enlighted. And that worked. 😃
Have you considered giving lsp a higher priority over cider-nrepl results? Will it lead to worse UX?
Calva has a setting allowing that. But for me the REPL is my truth so have left this at the default.
But I can look into if I can make the selection smarter. Right now it similar to (or nrepl clojure-lsp).