[Top][All Lists]

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

Re: Improvement proposals for `completing-read'

From: Daniel Mendler
Subject: Re: Improvement proposals for `completing-read'
Date: Thu, 8 Apr 2021 17:37:39 +0200

On 4/8/21 4:44 PM, Stefan Monnier wrote:
As long as we can offer some way (that's not too cumbersome) to select
between the different cases using things like self-insert-command + RET,
I'm fine with it.  IOW I think it require reifying the "subtle
differences" as some kind of optional extra text.
Okay, maybe I can come up with something.  This will require
experimentation. The duplicates could be deduplicated at the UI level by
appending some index for example "candidate (1)", "candidate (2)", ...

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.

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?

One thing to consider - maybe returning the highlights as some extra data is
not actually faster than simply propertizing the strings?

The extra opaque data is cheap/free to compute.  It would not contain
"the highlights", but just the side information that might be needed to
compute the highlights: e.g. you can't do the highlighting correctly for
`partial-completion` without having access to the "pattern" against
which it was matches.

I don't think this is true. At least not for the orderless style. There the pattern compiler compiles the input to the `completion-regexp-list`. This is fast for filtering but there is no way to obtain the highlights directly as far as I see it. Then in order to compute the highlights the highlighter once again has to receive the input pattern, generate the regexps and match them one by one, adding some faces to the strings.


reply via email to

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