[Top][All Lists]

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

Re: Improvement proposals for `completing-read'

From: Dmitry Gutov
Subject: Re: Improvement proposals for `completing-read'
Date: Thu, 8 Apr 2021 22:20:11 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1

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

reply via email to

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