hi @mfikes I see that planck returns a #js array of completions. inf-clojure just blindly calls read in elisp on this structure which fails due to the #js reader. Can you tell me why this is returned as a javascript array and not a clj immutable vector? Just trying to figure out where the correct bug report should go

@dpsutton Which API are you referring to?

get-completions

but i see that you pass that directly into the corejavascript stuff

Oh, that's not a public API

(defn- ^:export get-completions

get completions is exposed in repl. It is how inf-clojure asks for completions

See the minus sign after the defn?

ah yes i do. i missed that. sorry

That API actually just changed recently, fairly drastically, so if something is calling it, it may break

yeah it looks like inf-clojure was relying on that coming back as a list

There is one public API, planck.repl/get-arglists that was added for inf-clojure (and IIRC, Lumo has the same API with same semantics)

Perhaps another public API could be added for completions

would just suggest calling dir and doing it client side?

as it stands get-completions is fine if i strip off the #js and convert to a list in elisp

if that is intended to be stable that or something very similar that is meant for consumption would be fine

don't mean to hog your time if you are enjoying your sunday

But, it really has its own semantics, tied to the way it works with the Linenoise buffer. An example call might be (planck.repl/get-completions "(cljs.core/ma")

No, it wasn't intended to be stable. It internally changed what it was returning with https://github.com/mfikes/planck/commit/863b7b14383aa40427923f8bb5d11dc88a501a6f

I suppose if you build completions using dir then the result is fairly portable across REPLs.

Planck's completions include more than what dir gives though (so does Lumo).

One example is namespaces. Another is spec keywords.

But you will run into trouble if you assume it is doing what you might thing it is doing.

For example, compare (planck.repl/get-completions "fo") vs. (planck.repl/get-completions "for")

The first shows that you can complete "up to" for, while the second shows that you can complete with either for or force, which isn't included in the first result.

(This is just an example of how even the semantics are internal.)

ah i understand your point about linenoise now