Hi again, @bozhidar! I've taken a look at https://github.com/nrepl/nrepl/blob/master/src/clojure/nrepl/util/completion.clj, and I have a few thoughts about it. If I remember correctly, there was a need in nREPL to have some basic completion that does not rely on external dependencies and is compact. Totally understand that. But I see now that it has grown to 250 lines of code (yet, still less than compliment's 1000+ lines). While some of its code is very straightforward and easy to reproduce without pulling in an external solution, some things like classpath scanning and parsing out Java classes is not so trivial, and are already not 1:1 with Compliment (for example, if I read the source code right, it won't complete java.base classes in JDK9+). So with that in mind, do you consider the current approach of having to be the optimal one? I personally think that it is completely (hehe) fine, but there might also be some alternatives, depending on what are your primary criteria: • Is having 0 dependencies obligatory for nREPL? I'd say yes, cutting down on dependencies is overall a great practice. • Is using tools like mranderson undesirable for nREPL? • Is having all completion code as a single file obligatory? • Should the code for completion in nREPL live inside nREPL repository?

Depending on what is your stance on those questions, I could think of several approaches to increasing the reuse and consistency between Compliment and nrepl.util.completion. This also includes just keeping the current setup, but I would pay more attention to the nREPL's completion implementation and just backport Compliment fixes/important changes into it.

> Is having 0 dependencies obligatory for nREPL? I'd say yes, cutting down on dependencies is overall a great practice. Yeah, that's a hard requirement.

> Is using tools like mranderson undesirable for nREPL? I'd say - yes. The rewritten deps inflated cider-nrepl a lot in some case and forced extra complexity down the road like delayed middleware loading and so on. Perhaps for compliment it wouldn't be a big deal as it doesn't have deps itself, but I'd rather just copy the code from time to time than deal with MrAnderson's setup.

> Is having all completion code as a single file obligatory? Nope, this a problem for REPLy, but for nREPL it's all the same whether something is in one file or in multiple files.

Btw, there's one item to consider and this is REPLy itself - part of the reason I needed some simpler completion library was that we failed to get compliment working with it (I guess you remember this) and the original clojure-complete was kind of dead.

> Are you talking about something git submodules? Partially, yes, but I don't have a good success story with using submodules, so it depends whether you thought of it as a viable idea.

You might have noticed that I copied nREPL's completion code to one standalone library that I used to replace clojure-complete in REPLy.

Ah, no, didn't see that

> Partially, yes, but I don't have a good success story with using submodules, so it depends whether you thought of it as a viable idea. I'm not a big fan myself.

See https://metaredux.com/posts/2021/08/17/introducing-incomplete-a-simple-clojure-code-completion-library.html

The main fuzzy thing I have in mind right now is producing something like compliment-lite which could be somehow automatically derived from Compliment itself (Compliment can be refactored to accommodate that), which would not contain overcomplications like contexts and completion docs, and which could just live as a file artifact in the repository, not necessarily pushed as a JAR even.

> https://metaredux.com/posts/2021/08/17/introducing-incomplete-a-simple-clojure-code-completion-library.html I see! That makes it another place where the code gets duplicated and has to be maintained. Which is not the biggest problem in the world, I agree, it's all pretty much bike-shedding. But if I could tackle this without complicating things for other people, and you think it is something worth doing, I'd be willing to try.

I was also thinking such refactoring/reimagining can be coupled with finally moving Compliment under cider or even nrepl umbrella. I doubt it makes much sense to keep it a standalone project, given that most tool/IDE implementors just use nrepl or cider-nrepl directly and don't want to pull another third-party library.

That would be fine by me - I'm all for reducing code duplication. I'm assuming that with enough work we can change REPLy to work with compliment normally (e.g. we can just inline in there as well and remove the problematic dynamic load functionality).

Cool, then I'll work on a prototype and come back once I have something to show.

One more question, is there a reason why nrepl.util.completion is not 1:1 copy of incomplete? Do you take some notion of "complexity" into consideration as well?

@alexyakushev I'm guessing I forgot to update something after the initial release. I can't remember at this point, but I think I intended for them to be essentially the same.

@alexyakushev well, I use Compliment and Suitable without nRepl now, and I kinda want to keep doing it...

ClojureScript support with the shadow API is way better than over nRepl

And having the completion libs working without nRepl means that I don't loose functionality by deciding to use a different REPL implementation

@mauricio.szabo That's not going to change.

We're just discussing if we can use somehow compliment with nREPL directly, instead of its simplified completion mechanism.

@mauricio.szabo Thanks, that's good to know! I have no intention of removing Compliment as a standalone dependency, just some possible stewardship/repository changes

> moving Compliment under cider or even nrepl umbrella Think here simply of the GitHub org, not the projects themselves. 🙂

Wonderful, thanks for the clarification 😄

It's basically because I kinda bet on the idea of "tooling over socket-repl" and that bit me in the end, so now I'm scared/traumatized of implementing something that will not work in the future :rolling_on_the_floor_laughing: