|
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.
Daniel
[Prev in Thread] | Current Thread | [Next in Thread] |