Re: Improvement proposals for `completing-read'

[Daniel Mendler <mail@daniel-mendler.de>]

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