[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 19:46:06 +0000

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

I mentioned variable `icicle-transform-function', whose
most common values are `icicle-remove-duplicates' and
nil (which means don't remove dups).

(Like such a variable, completion metadata is an
aggregate operation: it applies to a set of completions,
not to just this or that completion.)

`icicle-transform-function' is applied to all candidates,
and it can do anything.

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

Don't confuse looking different in *Completions*, at the
outset and always, with easy to distinguish.  There are
other ways to make them appear different - from mode-line
to ephemeral appearance changes in *Completions*.  There
is more than one way to skin this cat.

> 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?

Don't rely on any one such thing.  Don't force UI
interactions into one channel.  Provide a general
mechanism (or more than one such).

> 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).


reply via email to

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