emacs-devel
[Top][All Lists]
Advanced

[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 17:22:16 +0000

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

Yes.

> But using it only for
> disambiguation should be okay. Then one would only compute the
> annotation when doing the actual completion?

No, annotations should not be used as the, or even as
a, means of disambiguating candidates.  That would be
an ugly and limiting hack.

Annotations are user-visible.  They have their own
use cases.  Making them take on the role of
disambiguating candidates - and especially making
them be _the_ means of disambiguating - would be
misguided, IMO.

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

That's a simple case.  Things get more complicated
for other kinds of matching.

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

Why "once again"?  Such highlighting should only be
done when displaying candidates (e.g. in *Completions*).

You have the generated composite regexp.  Why generate
it again?  You have it and you can use it - just
`string-match' candidates to highlight the matched parts.

reply via email to

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