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

[Drew Adams]

I wrote:

> 2. Completion candidates can be multi-part.  Each
>    part can be matched separately.  Use of any part
>    by a user is optional.

I meant to also mention that the matching can be
different for each part - even totally different.

> An example is choosing a file or buffer name.  The
> commands for this use multi-completion.  The first
> part of a candidate is the file or buffer name.
> The second part is the file or buffer content.
> The content part is _not_ shown in *Completions*.

And clearly those are examples of using different
kinds of matching for those parts.

This is quite different from just appending some
string bit to each candidate, to distinguish it,
and possibly hiding that to prevent matching etc.,
which you are discussing as a way to fulfill the
need of disambiguating "duplicates".

There are multiple ways to disambiguate duplicates.
I mentioned this one, and I mentioned giving each
string candidate the "full" candidate as a text
property.

What you're describing (leveraging annotations) is
pretty limited in terms of what it allows for
completion behavior (for users).