compliment.sources.class-members could add the class to its candidates

[behrica]

 (compliment.core/completions ".abs")
({:candidate ".abs", :class "java.lang.BigInteger", :type :method})

or similar.
This would allow downstream tools to filter candidates "by class",
which can be useful for completion scenarios on which the precise class cannot be infered from context.

[alexander-yakushev]

I have a couple of questions.

1. Compliment returns a list of members with unique names, so .abs will only be suggested once, but multiple classes have a method .abs. So, your example would rather look like { :candidate ".abs", :type :method, :classes ["java.math.BigInteger" "java.math.BigDecimal" "java.math.BigDecimal"]. Is this OK?
2. @vemv Is there a way to leverage this later from CIDER? Generating those lists of classnames slows down completion a little bit. I'm fine hiding it behind an *extra-metadata* flag, then the regular case won't be impacted, but the extra path will be slower. I can also precompute/cache the lists, which makes the extra path fast again for the cost of additional memory for cache. So, I'd be willing to implement this if there's a frontend in sight that consumes this, otherwise I'm not sure it's worth the overhead.

[behrica]

I was proposing a feature in Cider which at least allows to "show" this class names optionally in the completion drop downs.
I think this could be useful for all cases, where the user does not want to type hint code to get precise method candidates.
Ideally IDEs would then allow to "filter" or "group" completion lists, but I understood that this would be more difficult to implement from an UI point of view.

Calva uses as well "compliment" , does it ?

[vemv]

From CIDER's point of view, having Compliment return this extra info makes no difference.

We can have all the info we need by querying Compliment first and then Orchard can gives us further info (we already follow that pattern elsewhere).

IMO starting this discussion at the Compliment level is wrong.

First you should specify which UI you intend to use. If it's Emacs, it has to be one of company/corfu/... (I don't mind which, the point is to be specific). If it's Calva, that's fine too but we need to know that with certainty as well.

It's also very important to understand that Compliment showing ambiguous completions is not the intended normal scenario. You should provide type hints for proper Java interop, evaluate sexprs for correct functioning, and when that doesn't suffice, we should fix #111 #113 first and then re-evaluate our solution.

If the mentioned GH issues were implemented, you would experience the problem 1% of the time and we would not have to complicate things in any part of the stack.

This is the original thread, for reference. https://clojurians.slack.com/archives/C0617A8PQ/p1699705382658719

Cheers - V

[alexander-yakushev]

@behrica Yes, I believe Calva uses compliment. If there's a UI approach in Calva that is ready to leverage such extra information from Compliment, I'll be glad to implement it.

@vemv Having to query the data additionally for each candidate is not the same, since you need to, well, query each candidate. So it's a 1+N problem, or you can't make filtering work.

I won't necessarily agree that Compliment showing all methods is an edge case while having a type hint is a default scenario. I think it is the other way around. Ultimately, it depends on personal preferences (write hints first or add them later). I usually do the latter.