Re: Improvement proposals for `completing-read'

[Dmitry Gutov]

On 08.04.2021 18:37, Daniel Mendler wrote:

> > I think we should arrange for the completion table to provide that extra
> > text, so it can be more meaningful than an arbitrary number.  Also the
> > user needs to be able to know "which is which", so it needs to be
> > connected to something that's displayed in *Completions* that
> > distinguishes them.
>
> Yes, that would be the best possibility. There are many ways to provide 
> that data: Via a text property, via an extra metadata function, etc. In 
> the case of Swiper the extra data could simply be the line number. 
> However a general solution should also automatically generate indices, 
> since it is probably better to not require the completion table to 
> provide the information in any case. I would like some graceful 
> degradation.

Another approach would be to add a new "extra property" or metadata 
element which will say "don't remove duplicates".

I do think it's questionable, though, to include completions that are 
hard to distinguish.

> > E.g. maybe we could arrange for the minibuffer text to be
> > matched against the *annotated* candidates in some cases.  I think this
> > requires more thought, together with concrete examples.
>
> Generally matching against annotations functions is problematic. As I 
> interpret things, the point of annotations is that they are not 
> matchable. Maybe they are more expensive to compute, so this should 
> happen lazily for the displayed candidates. But using it only for 
> disambiguation should be okay. Then one would only compute the 
> annotation when doing the actual completion?

Matching on annotations is indeed problematic. And if such conflicts are 
rare, perhaps we could rely on the user making the final choice using 
the *Completions* buffer?

Further, that's only important if the choice between them is actually 
important (and we weren't using them just to display, say, all available 
overloads of a method in the completion popup).