RE: [External] : Re: Improvement proposals for `completing-read'

[Drew Adams <drew.adams@oracle.com>]

> >> But using it only for disambiguation should be okay.
> >> Then one would only compute the annotation when
> >> doing the actual completion?
> >
> > No, annotations should not be used as the, or even as
> > a, means of disambiguating candidates.  That would be
> > an ugly and limiting hack.
> >
> > Annotations are user-visible.  They have their own
> > use cases.  Making them take on the role of
> > disambiguating candidates - and especially making
> > them be _the_  means of disambiguating - would be
> > misguided, IMO.
> 
> That's exactly why they are a good means of disambiguating completions:
> completions with different annotations have something for the user to
> distinguish them with.

That's backward.  Users can distinguish them (when
the annotations differ).  It doesn't follow that
that's the best or only way to distinguish candidates.

There can be _lots_ of info that's part of a full
candidate which we do _not_ expose in the UI, so
users don't necessarily see a difference in
*Completions*.

We can nevertheless make any such info visible in
other ways, e.g. on demand.

Regardless, nothing says that some of the info we
use to distinguish candidates (for whatever reasons,
including maybe performance) needs to also be
user-visible.

And nothing says that the best or only way to make
some such info visible to users is using annotations.

Annotations are just one tool.  Not everything is a
nail.

There's a difference between making something visible
and making it matchable.  It's good to have something
that can serve as an unmatchable annotation.  We have
that.

What's useful is to add a new feature: letting
candidates themselves have additional matchable parts,
which can be, but need not be, displayed.

A (full) candidate, itself, already and necessarily
contains whatever info is needed to distinguish it -
makes it unique.  An annotations is (intentionally)
not part of a candidate.