[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Drew Adams
Subject: RE: [External] : Re: Improvement proposals for `completing-read'
Date: Thu, 8 Apr 2021 18:33:13 +0000

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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]